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Foreword 


This  publication,  the  Pinal  Evaluation  Report  Addendum  of  American  Telephone 
and  Telegraph  Incorporated's,  System  V/MLS,  is  being  issued  by  the  National 
Computer  Security  Center  under  the  authority  of  and  in  accordance  with  DoD 
Directive  5215.1,  "Computer  Security  Evaluation  Center."  The  purpose  of  this 
report  is  to  document  the  current  evaluation  AT&T's  System  V/MLS  operating 
system  and  incorporate  the  changes  that  were  approved  at  the  Rating 
Maintenance  Technical  Review  Board.  The  requirements  stated  in  this  report 
are  taken  from  Department  of  Defense  Trusted  Computer  System  Evaluation 
Criteria,  dated  December  1985. 
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Executive  Summary 


The  security  protection  provided  by  the  AT&T  System  V/MLS  (System  V./MLSj  operating  system, 
configured  as  described  in  the  Trusted  Facility  Manual,  when  running  on  the  AT&T  3B2/500  or 
3B2/600  minicomputers,  has  been  evaluated  by  a  National  Security  Agency,  Trusted  Product  and 
Network  Security  Evaluation  Team.  Tae  security  features  of  System  V/MLS  were  examined 
against  the  requirements  specified  by  the  DoD  Trusted  Computer  System  Evaluation  Criteria  (the 
Criteria  or  TCSEC)  dated  26  December  1985  in  order  to  establish  a  TCSEC  rating. 

The  National  Security  Agency  Evaluation  team  has  determined  that  the  highest  class  at  which 
System  V/MLS  satisfies  all  the  specified  requirements  of  the  Criteria  is  class  Bl.  Therefore 
System  V/MLS  when  configured  in  the  manner  described  in  the  Trusted  Facility  Manual,  has  been 
assigned  a  class  Bl  rating. 

A  system  that  has  been  rated  as  being  a  Bl  class  system  provides  a  Trusted  Computing  Base  (TCB) 
that  preserves  the  integrity  of  sensitivity  labels  and  uses  them  to  enforce  a  set  of  mandatory  access 
control  rules. 

The  UNIX  System  V  operating  system  is  a  general  purpose  time-sharing  system.  System  V/MLS 
an  enhanced  version  of  UNIX  system  V,  was  developed  to  meet  the  Bl  Criteria  while  maintaining 
compatibility  with  UNIX  System  V.  System  V/MLS  maintains  a  security  audit  trail,  provides 
mandatory  access  control,  and  includes  other  security  features  such  as  a  random  password 
generator,  a  trusted  version  of  the  Bourne  shell,  and  a  trusted  administrative  interface.  There  is 
also  a  configuration  management  plan  in  effect  for  this  system  to  allow  participation  in  the 
Ratings  Maintenance  Phase  (RAMP). 
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1.  Introduction 

In  October  1988,  the  National  Security  Agency  (NSA)  Trusted  Product  and  Network  Security 
Evaluation  Division  (TPNSE)  began  a  formal  product  evaluation  of  System  V/MLS,  an  American 
Telephone  and  Telegraph  (AT&T)  product.  It  is  intended  that  this  report  give  evidence  and 
analysis  of  the  security  features  and  assurances  provided  by  the  System  V/MLS  operating  system. 
This  report  documents  the  system’s  security  design  and  appraises  its  functionality  and  assurances 
against  the  Criteria’s  B1  security  requirements.  This  evaluation  applies  to  System  V/MLS  Release 
1.2.0  running  on  UNIX  System  V  Release  3.1.1. 

The  System  V/MLS  product  adds  mandatory  access  control  and  auditing  capabilities  to  UNIX 
System  V.  It  is  integrated  with  UNIX  System  V  at  install  time  via  an  overlay  procedure.  Some 
UNIX  System  V  routines  were  rewritten  for  System  V/MLS,  and  others  were  added.  Hooks  were 
inserted  in  the  underlying  UNIX  System  V  routines  to  call  the  new  System  V/MLS  routines. 

Although  System  V/MLS  is  a  separate  product  from  UNIX  System  V,  throughout  this  report 
System  V/MLS  will  be  referred  to  as  the  whole  integrated  system.  Statements  referencing  only 
those  routines  unique  to  the  System  V /MLS  product  are  clarified  to  reflect  the  exact  meaning. 

The  updates  to  this  report  were  gathered  by  AT&T  Vendor  Security  Analysts  (VSA’s),  on  behalf  of 
the  Trusted  Product  and  Network  Security  Evaluation  Division,  through  documentation,  interaction 
with  system  developers,  and  hands  on  use  of  System  V/MLS. 

1.1  Evaluation  Process  Overview 

The  Department  of  Defense  Computer  Security  Center  was  established  in  January  1981  to 
encourage  the  widespread  availability  of  trusted  computer  systems  for  use  by  facilities  processing 
classified  or  other  sensitive  information.  In  August  1985  the  name  of  the  organization  was  changed 
to  the  National  Computer  Security  Center.  In  order  to  assist  in  assessing  the  degree  of  trust  one 
could  place  in  a  given  computer  system,  the  DoD  Trusted  Computer  System  Evaluation  Criteria 
(TCSEC)  was  written.  The  TCSEC  establishes  specific  requirements  that  a  computer  system  must 
meet  in  order  to  achieve  a  predefined  level  of  trustworthiness.  The  TCSEC  levels  are  arranged 
hierarchically  into  four  major  divisions  of  protection,  each  with  certain  security-relevant 
characteristics.  These  divisions  are  in  turn  subdivided  into  classes.  To  determine  the  division  and 
class  at  which  all  requirements  are  met  by  a  system,  the  system  must  be  evaluated  against  the 
TCSEC  by  an  NSA,  Trusted  Product  and  Network  Security  evaluation  team. 

The  NCSC  supports  the  creation  of  secure  computer  products  in  varying  stages  of  development  from 
initial  design  to  those  that  are  commercially  available.  Preliminary  to  an  evaluation,  products  must 
go  through  the  Proposal  Review  Phase.  This  phase  includes  an  assessment  of  the  vendor’s 
capability  to  create  a  secure  system  and  complete  the  evaluation  process.  To  support  this 
assessment  a  Preliminary  Technical  Review  (PTR)  of  the  system  is  done  by  the  NSA.  This  consists 
of  a  quick  review  of  the  current  state  of  the  system  by  a  small  but  expert  team  and  the  creation  of  a 
short  report  on  the  state  of  the  system.  If  a  vendor  passes  the  Proposal  Review  Phase  they  will 
enter  a  support  phase  preliminary  to  evaluation.  This  support  phase  has  two  steps,  the  Vendor 
Assistance  Phase  (VAP)  and  the  Design  Analysis  Phase  (DAP).  During  VAP,  the  newly  assigned 
team  reviews  design  specifications  and  answers  technical  questions  that  the  vendor  may  have  about 
the  ability  of  the  design  to  meet  the  requirements.  A  product  will  stay  in  VAP  until  the  vendor’s 
design,  design  documentation,  and  other  required  evidence  for  the  target  TCSEC  class  are  complete 
and  the  vendor  is  well  into  implementation.  At  that  time,  the  support  moves  into  DAP. 
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The  primary  thrust  of  DAP  is  an  in-depth  examination  of  a  manufacturer’s  design  of  either  a  new 
trusted  product  or  for  security  enhancements  to  an  existing  product.  DAP  is  based  on  design 
documentation  and  information  supplied  by  the  industry  source,  it  involves  little  'hands  on'  use  of 
the  system.  DAP  results  in  the  production  of  an  Initial  Product  Assessment  Report  (IPAR)  by  the 
NSA  assessment  team.  The  IPAR  documents  the  team’s  understanding  of  the  system  based  on  the 
information  presented  by  the  vendor.  Because  the  IPAR  contains  proprietary  information  and 
represents  only  a  preliminary  analysis  by  the  NSA,  distribution  is  restricted  to  the  vendor  and  the 
NSA. 

Products  that  have  completed  the  support  phase  with  the  successful  creation  of  the  IPAR,  enter 
formal  evaluation.  Products  entering  formal  evaluation  must  be  complete  security  systems.  In 
addition,  the  release  being  evaluated  must  not  undergo  any  additional  development.  The  formal 
evaluation  is  an  analysis  of  the  hardware  and  software  components  of  a  system,  all  system 
documentation,  and  a  mapping  of  the  security  features  and  assurances  to  the  TCSEC.  The  analysis 
preformed  during  formal  evaluation  requires  'hands  on'  testing  (i.e.,  functional  testing  and,  if 
applicable,  penetration  testing).  The  formal  evaluation  results  in  the  production  of  a  Hnal  report 
and  an  Evaluated  Products  List  (EPL)  entry.  The  final  report  is  a  summary  of  the  evaluation  and 
includes  the  EPL  rating  which  indicates  the  final  class  at  which  the  product  satisfies  all  TCSEC 
requirements  in  terms  of  both  features  and  assurances.  The  final  report  and  the  EPL  entry  are 
m^uie  public. 

After  completion  of  the  Formal  evaluation  phase,  product  rated  at  B1  and  below  enter  the  rating 
maintenance  phase  (RAMP).  The  ratings  maintenance  phase  provides  a  mechanism  extend  the 
previous  rating  to  a  new  version  of  an  evaluated  computer  system  product.  As  enhancements  are 
made  to  the  computer  product  the  ratings  maintenance  phase  ensures  that  the  level  of  trust  is  not 
degraded. 

Rating  Maintenance  is  accomplished  by  using  qualified  vendor  personnel  to  manage  the  change 
process  of  the  rated  product  during  the  maintenance  cycle.  These  qualified  vendor  personnel  must 
have  strong  technical  knowledge  of  computer  security  and  of  their  computer  product.  These  trained 
personnel  will  oversee  the  vendor’s  computer  product  modification  process.  They  will  demonstrate 
to  the  Trusted  Product  and  Network  Security  Evaluation  Division  that  any  modification  or 
enhancements  applied  to  the  product  preserve  the  security  mechanisms  and  maintain  the  assurances 
required  by  the  TCSEC  for  the  rating  previously  awarded  to  the  evaluated  product. 

1.2  Document  Organisation 

This  report  consists  of  four  major  sections  and  four  appendices.  Section  1  is  an  introduction. 
Section  2  provides  an  overview  of  the  system  hardware  and  software  architecture.  Section  3 
provides  a  mapping  between  the  requirements  specified  in  the  Criteria  and  the  System  V/MLS 
features  that  fulfill  those  requirements.  Section  4  presents  the  evaluation  team’s  personal  opinions 
about  System  V/MLS.  The  appendices  identify  specific  hardware  and  software  components  to 
which  the  evaluation  applies,  list  the  trusted  computing  base  components  in  the  system,  provide  a 
bibliography  for  this  report,  and  the  evaluated  product  listing. 
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2.  System  Overview 

This  section  begins  with  a  brief  description  of  the  history  of  the  System  V/MLS  system,  and  then 
describes  the  security-relevamt  architecture  and  mechanisms. 

2.1  System  Y/MLS  Backgrotmd  and  History 

In  1969  Ken  Thompson,  Dennis  Ritchie  and  other  employees  at  Bell  Laboratories  developed  the 
UNIX*  operating  system,  a  time  sharing  system  implemented  on  a  Digital  Elquipment  Corporation 
model  PDP-7  computer. 

In  1973  UNIX  was  rewritten  in  the  high  level  language  C  from  the  original  assembler  language.  This 
made  the  system  more  readily  understandable  and  portable  to  different  hardware  bases. 

The  portability  of  the  system  led  to  its  use  on  numerous  hardware  architectures.  By  1977  the 
number  of  sites  using  the  UNIX  operating  system  had  grown  to  approximately  500.  During  the  next 
ffve  years  Bell  Laboratories  enhanced  the  system  and  eventually  released  the  UNIX  System  III 
version.  The  UNIX  System  IV  version  was  internal  to  AT&T  and  not  released  commercially.  By 
1983  Bell  Laboratories  added  several  features  and  announced  the  System  V  version  of  UNIX. 

In  1984-1985  the  AT&T  Federal  Systems  Division,  which  had  been  working  towards  the 
development  of  a  secure  UNIX  operating  system,  developed  "SecPac',  a  UNIX  operating  system 
add-on  security  package.  SecPac  provided  rudimentary  data  sensitivity  labeling,  mandatory 
protection,  and  a  detailed  audit  trail.  SecPac  was  then  modified  and  refined  into  the  current 
System  V/MLS  product. 
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2.2  Hardware  Architecture 

The  AT&T  System  V/MLS  Trusted  Computing  Base  (TCB)  consists  of  two  primary  elements:  the 
system  hardware,  and  the  system  software.  It  is  the  purpose  of  the  hardware  to  provide  an 
environment  which  the  software  can  use  to  implement  a  complete  and  trusted  interface  to  the 
system.  The  following  section  will  describe  the  hardware  and  how  it  provides  the  necessary  support 
for  the  system  software. 

2.2.1  Hvalnated  Canfigorations 

The  evaluated  configurations  of  System  V/MLS  include  two  hardware  models,  the  AT&T  3B2/500 
and  3B2/600,  with  support  for  the  AT&T  630  Multi-Tasking  Graphics  (MTG)  terminal,  the  AT&T 
4425  terminal,  the  AT&T  605  BCT  terminal,  and  the  AT&T  5310  printer.  Both  of  the  host 
machine  models  utilize  the  WE  32100  Microprocessor  and  the  WE  32101  Memory  Management 
Unit. 

The  AT&T  3B2/500  is  configured  with  4M  bytes  of  RAM  (8M  bytes  maximum),  147M  bytes  of 
hard  disk  storage  which  is  accessed  through  a  Smadl  Computer  System  Interface  (SCSI)  card,  floppy 
disk  drive,  60M  byte  cartridge  tape  drive  (SCSI  interface),  and  support  for  a  virtual  cache  option. 

The  AT&T  3B2/600  is  nearly  identical  in  architecture  to  the  3B2/500,  with  slightly  different 
standard  components.  The  3B2/600  is  configured  with  4M  bytes  of  RAM  (16M  bytes  maximum), 
294M  bytes  of  hard  disk  storage  (SCSI  interface),  floppy  disk  drive,  60M  byte  cartridge  tape  drive 
(SCSI  interface),  and  a  virtual  cache  card.  The  3B2/600  also  supports  a  multiprocessor 
enhancement,  which  is  not  included  in  the  evaluated  configuration. 

Both  of  these  system  models  provide  32-bit  data  and  address  paths,  as  well  as  Error  Correcting  Code 
(ECC)  RAM  to  detect  and  correct  single  bit  errors  and  detect  double  bit  errors.  Both  provide 
suppmrt  for  the  WE  32106  Math  Acceleration  Unit. 

The  evaluated  configuration  includes  three  types  of  terminals;  two  ordinary  terminals  and  an 
intelligent  terminal,  the  AT&T  630  Multi-Tasking  Graphics  terminal.  The  630  MTG  incorporates 
640K  bytes  of  RAM  (IM  byte  maximum),  a  Motorola  68000  microprocessor  and  a  bitmapped 
display  with  a  1,024  x  1,024  resolution.  The  terminal  allows  a  user  to  create  multiple  windows 
operating  concurrently  at  different  security  leveb,  allows  window-to-window  operations,  and 
provides  a  trusted  communications  path. 

2.2.2  Hardware  Companents 

2.2.2.1  Central  Processing  Unit  Subsystem 

System  V/MLS  utilizes  the  Western  Electric  32100  Microprocessor  (WE  32100  or  CPU)  to  provide 
computational  and  security  functionality.  The  WE  32100  is  a  32-bit  central  processing  unit  which 
supports  a  4  Gigabyte  address  space,  via  32-bit  data  and  address  buses.  The  WE  32100  has  a  64- 
word  on-chip  instruction  cache.  All  memory  addresses  for  instruction  fetch  and  data  go  through  the 
Western  Electric  32101  Memory  Management  Unit  (WE  32101  or  MMU)  in  System  V/MLS  to 
provide  a  virtual  memory  environment. 

Sixteen  32-bit  registers  are  available  on  the  WE  32100,  consisting  of  thirteen  general-access  registers, 
and  three  kemel-privileged  (for  write  access)  registers.  The  kernel-privileged  registers  were  designed 
specifically  to  support  the  concept  of  a  process  within  the  CPU.  This  design  provides  a  convenient 
and  efficient  mechanism,  upon  which  UNIX  was  built. 
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2.2.2.1.1  Processor  Execution  Modes 

The  WE  32100  supports  four  execution  modes:  kernel,  executive,  supervisor,  and  user.  Of  these, 
only  kernel  and  user  mode  are  used.  The  design  of  the  3B2  system  hardware  ensures  that  neither  of 
the  other  two  modes  is  usable. 

The  execution  modes  serve  two  purpcwes;  first,  they  dictate  which  instructions  are  available  for 
execution,  and  second,  they  are  used  by  the  MMU  to  enforce  restrictions  upon  access  to  data. 
Kernel  mode  is  the  most  privileged;  in  this  mode  all  instructions  are  available  for  execution.  User 
mode  is  the  least  privileged;  all  user  progranas  are  executed  in  user  mode.  Only  the  execution  of  a 
system  call  transfers  the  processor  hrom  user  to  kernel  mode. 

2.2.2.1.2  Execution  Mode  Switching 

The  system  call  (gate)  mechanism  provides  a  means  of  controlled  changes  of  the  processor  execution 
mode  by  installing  new  Processor  Status  Word  (PSW)  and  Program  Counter  (PC)  register  values. 
If  the  new  PSW  has  a  different  processor  execution  mode  than  the  current  PSW,  a  transition  to  the 
new  mode  occurs. 

The  GATE  and  RETG  instructions  are  used  to  switch  processor  execution  modes  (see  'Instruction 
Set'  below).  GATE  performs  the  actual  PSW  switch,  from  which  the  processor  deduces  its  current 
execution  mode  by  examining  the  PSW  value.  RETG  is  used  to  return  from  the  environment  which 
was  'GATEd'  to,  and  in  doing  so,  RETG  forces  the  new  execution  mode  to  be  less  privileged  than 
or  equal  to  the  current  mode. 

2.2.2.1.3  Instruction  S«t 

The  CPU  implements  179  instructions,  of  which  9  are  provided  to  directly  support  operating  system 
functions.  Those  opcodes  for  which  there  is  no  corresponding  instruction  generate  an  illegal  opcode 
exception  when  executed. 

The  instructions  designated  for  supporting  an  operating  system  are  those  that  can  change  the 
physical  state  of  the  processor,  respond  to  interrupts,  or  permit  changing  the  process  that  is 
currently  executing  on  the  CPU.  Of  the  nine  operating  system  instructions,  six  require  the 
processor  to  be  in  kernel  mode  for  execution.  The  kernel  mode  (privileged)  instructions  are: 

.  CALLPS, 

.  DISVJMP, 

.  ENBVJMP, 

.  INTACK, 

.  RETPS,  and 

.  WAIT. 

If  these  instructions  are  executed  in  other  than  kernel  mode,  a  privileged  opcode  exception  occurs. 
The  remaining  three  operating  system  instructions  are:  GATE,  MOVTRW,  and  RETG,  which  may 
be  executed  while  the  CPU  is  in  any  processing  mode. 
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The  following  is  a  discussion  of  the  operating  system  instructions: 

Call  Process:  CALLPS  performs  a  process  switch,  saving  the  current  process 

image  and  entering  a  new  process.  CALLPS  saves  the  context 
(register  contents)  of  the  current  process,  pushes  the  current 
Process  Control  Block  Pointer  (PCBP)  onto  the  interrupt  stack, 
places  a  new  PCBP  into  the  PCBP  register,  sets  the  Process 
Status  Word,  Program  Counter,  and  Stack  Pointer  registers,  and 
then  exits. 

Disable  Virtual  Pin  and  Jump:  DISVJMP  changes  the  CPU  to  physical  addressing  mode 

(disabling  the  MMU)  and  puts  a  new  value  into  the  PC  register. 

Enable  Virtual  Pin  and  Jump:  ENBVJMP  enables  the  virtual  address  pin  for  the  CPU,  allov  ng 

the  MMU  to  perform  address  mapping  for  the  virtual 
environment. 

Interrupt  Acknowledge:  INTACK  is  used  to  generate  an  acknowledge  signal  from  the  CPU 

to  an  interrupting  peripheral.  This  allows  the  system  to  correctly 
acknowledge  interrupts. 

Return  to  Process:  RETPS  terminates  the  current  process  (without  saving  its 

context)  and  returns  to  the  process  whose  PCBP  is  on  the  top  of 
the  interrupt  stack. 

Wait  for  Interrupt:  WAIT  halts  the  CPU,  stopping  instruction  fetching  and  execution 

until  an  interrupt  or  external  reset  occurs. 

Gate;  GATE  is  used  to  change  the  value  of  the  PSW  and  PC  registers  of 

the  CPU,  potentially  placing  the  CPU  into  a  new  processing  mode. 
The  instruction  retrieves  new  PSW  and  PC  register  values  from  a 
protected  memory  area  (write  permission  while  in  kernel  mode 
only)  to  prevent  unexpected  processing  mode  changes.  GATE  is 
used  in  conjunction  with  RETG,  for  valid  processor  execution 
mode  switches. 

Move  Translated  Word:  MOVTRW  tells  the  MMU  to  intercept  the  virtual  address  sent  by 

the  processor,  translate  it,  and  return  the  physical  address  to  the 
destination  specified  in  the  instruction. 

Return  From  Gate:  RETG  is  very  similar  to  a  simple  return  from  subroutine 

instruction,  with  the  exception  that  RETG  enforces  a  linear 
ordering  of  execution  modes.  The  linear  ordering  will  not  allow  the 
new  execution  mode  to  be  more  privileged  than  the  current  mode. 
RETG  is  used  in  conjunction  with  GATE  to  switch  the  execution 
mode  of  the  processor. 

2.2.2.1.4  Registers 

Sixteen  32'bit  registers  are  provided  with  the  CPU;  nine  of  these  registers  are  for  general  use  (rO  - 

rS),  while  seven  are  special-purpoee  registers  (r9  -  rl5).  The  intended  functions  for  these  registers 

are  described  below. 
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2.2.2.1.4.1  Operating  System  Support  Renters 

The  WE  32100  supports  the  abstraction  of  processes  through  the  use  of  three  kernel-privileged 
registers,  the  Process  Status  Word,  Process  Control  Block  Pointer,  and  Interrupt  Stack  Pointer.  In 
this  context,  kernel-privileged  means  that  the  register  can  only  be  written  while  the  CPU  is  in  kernel 
execution  mode. 

The  Process  Status  Word  (PSW  or  rll)  contains  status  information  about  the  microprocessor  and 
the  current  process.  The  PSW  also  contains  four  condition  code  flags  used  in  transfer-of-control 
instructions. 

The  Process  Control  Block  Pointer  (PCBP  or  rl3)  points  to  the  starting  address  of  the  process 
control  block  for  the  current  process.  The  process  control  block  is  a  data  structure  in  main  memory 
containing  the  hardware  context  of  a  process  when  the  process  is  not  running.  This  context  consists 
of  the  initial  and  current  contents  of  the  PSW,  Program  Counter,  and  Stack  Pointer;  the  contents  of 
the  user  registers;  boundaries  for  an  execution  stack;  and  block  move  specifications  (whether  or  not 
block  moves  are  allowed)  for  the  process. 

The  Interrupt  Stack  Pointer  (ISP  or  rl4)  contains  the  32-bit  memory  address  of  the  top  of  the 
interrupt  stack.  This  stack  is  used  when  an  interrupt  request  is  received.  In  addition,  the  stack  is 
used  by  the  call  process  (CALLPS)  and  return  to  process  (RETPS)  instructions. 

2.2.2.1.4.2  Conventional  Renters 

The  CPU  has  nine  general-purpose  registers  (rO  -  r8),  the  Frame  Pointer,  Argument  Pointer,  Stack 
Pointer,  and  the  Program  Counter  registers.  These  registers  are  aU  accessible  (for  both  read  and 
write  access)  in  any  execution  mode  of  the  processor. 

The  general-purpose  registers  (rO  -  r8)  are  used  for  intermediate  data  storage,  arithmetic,  data 
transfer,  logical,  and  program  control  assembly  instructions.  Registers  rO,  rl,  and  r2  are  additionally 
used  for  string  manipulation  and  transfer  instructions  and  for  return  code  values  in  C  programs. 

The  Frame  Pointer  (r9)  and  Argument  Pointer  (rlO)  registers  are  used  primarily  for  support  of 
higher-level  programming  languages.  By  convention,  the  Frame  Pointer  points  to  the  beginning 
location  in  the  stack  of  a  function’s  local  variables.  The  Argument  Pointer  points  to  the  beginning 
location  in  the  stack  to  which  a  set  of  arguments  for  a  function  have  been  pushed. 

The  Stack  Pointer  (SP  or  rl2)  contains  the  address  of  the  top  of  the  current  execution  stack,  i.e. 
the  next  available  memory  location  on  the  stack  for  data  storage.  The  Program  Counter  (PC  or 
rl5)  contains  the  address  of  the  currently  executing  instruction  or,  on  completion,  the  starting 
address  of  the  next  instruction. 

2.2.2.1.S  Interropt  Handling 

The  WE  32100  accepts  fifteen  levels  of  interrupts.  An  interrupt  request  is  made  to  the  processor 
by  placing  an  interrupt  request  value  on  the  interrupt  priority  level  pins  of  the  CPU  or  by 
requesting  a  nonmaskable  interrupt  by  asserting  the  NMINT  line  of  the  CPU.  Pending  interrupts 
are  not  acknowledged  until  the  current  instruction  completes,  except  in  the  case  of  instructions 
which  must  loop  in  the  course  of  their  processing,  such  as  the  MOVBLW  (move  block)  instruction. 
In  the  case  of  these  instructions,  interrupts  are  enabled  at  the  end  of  each  pass  through  the  loop, 
and  disabled  at  the  start  ci  each  pass  through  the  loop. 

The  pending  interrupt  value  is  compared  to  the  value  contained  in  the  Interrupt  Priority  Level 
(IPL)  field  of  the  PSW.  For  the  pending  interrupt  to  be  acknowledged,  its  inverted  value  must  be 
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greater  than  the  IPL  value,  except  for  the  NMINT,  which  is  always  received. 

The  processor  acknowledges  an  interrupt  by  placing  the  inverted  interrupt  request  value  on  the 
address  bus.  The  interrupt  request  value  is  received  by  the  interrupting  device,  which  then  returns 
an  8-bit  offset  into  the  full  interrupt  table  which  then  points  to  an  interrupt  handler  for  execution. 
Upon  completion  of  the  interrupt  handler,  the  next  instruction  from  the  interrupted  process  is 
executed.  For  NMINT  interrupts,  the  CPU  assumes  address  0x8c  (hex  8c)  contains  the  PCBP  of 
the  interrupt  handling  routine;  thus  it  transfers  to  this  PCBP  when  an  NMINT  occurs. 

2.2.2.1.6  Math  Acceleration  Unit 

The  WE  32106  Math  Acceleration  Unit  (MAU)  is  supported  in  System  V/MLS,  and  is  used  to 
provide  increased  system  performance.  The  MAU  provides  floating-point  capability  for  System 
V/MLS,  in  single,  double,  and  double-extended  precision.  Operands,  results,  status,  and  commands 
are  transferred  over  an  internal  system  bus,  providing  the  interface  to  the  host  processor. 

2.2.2.2  Memory  Subsystem 

System  V/MLS  makes  use  of  the  WE  32101  Memory  Management  Unit  to  provide  a  separate 
virtual  address  space  for  each  user.  This  virtual  environment  allows  the  system  to  support  multiple 
users,  while  maintaining  separation  between  those  users  and  the  kernel  code  and  data. 

2.2.2.2.1  Memory  Layout 

The  virtual  address  space  is  divided  into  four  sections  by  the  MMU;  each  section  is  up  to  IG  byte  in 
siie.  Two  sections  are  used  to  map  kernel  address  space,  and  two  are  used  to  map  user  address 
space.  Each  section  is  then  further  subdivided  into  segments,  which  b  in  turn  divided  into  pages. 
Pages  are  2K  bytes  in  extent. 

System  V /MLS  supports  virtual  memory  by  paging.  The  paging  scheme  allows  a  process  to  exist  in 
primary  memory  with  a  minimal  memory  requirement,  thus  allowing  more  processes  to  be  active  at 
any  given  time  than  could  actually  fit  into  memory  concurrently.  At  any  point  in  time,  some  pages 
for  a  given  process  may  reside  in  primary  memory  while  others  exist  on  secondary  storage.  If  a 
process  attempts  to  access  a  page  that  is  not  resident  in  primary  memory  a  fault  occurs,  and  the 
needed  page  is  brought  in  from  secondary  memory.  The  page  replacement  algorithm  is  called  'least 
recently  used  second  chance  replacement'.  See  page  25,  'Memory  Allocation'  for  additional 
information. 

2.2.2.2.2  Address  Translation  Mechanism 

The  CPU  generates  a  virtual  address,  which  is  translated  by  the  MMU  into  a  corresponding  physical 
address.  This  translation  process  involves  the  actual  virtual-to-physical  translation  and  checks  to 
determine  that  access  should  be  granted  to  the  requested  memory  page  based  upon  the  segment 
based  access  permissions. 

The  MMU  performs  address  translation  (see  Figure  1)  using  descriptors  that  contain  the 
information  necessary  for  segment  and  page  mapping.  The  MMU  has  two  types  of  descriptors: 
segment  descriptors  (SD)  for  mapping  the  paged  segments,  and  page  descriptors  (PD)  for  mapping 
pages  within  the  paged  segments. 

A  SD  consists  of  two  32-bit  words.  The  first  word  contains  information  about  the  segment,  while 
the  second  word  contains  the  physical  address  for  the  Page  Descriptor  Table  (PDT)  for  the  segment. 
Information  within  a  SD  identifies  whether  the  segment  is  present  in  memory,  has  been  modified,  is 
cacheable,  has  been  referenced,  what  the  access  permissions  for  the  segment  are,  and  other  data 
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about  the  segment. 

A  Page  Descriptor  Table  is  associated  with  each  memory  segment  in  the  system.  The  PDT 
maintains  page  descriptors  for  each  page  within  a  segment.  It  is  these  page  descriptors  that 
ultimately  reflect  the  physical  location  of  a  memory  page.  Page  descriptors  are  composed  of 
information  such  as  the  physical  presence  of  the  page,  modified  status,  reference  indicator,  physical 
address  of  page,  and  similar  status  data. 
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Figure  1.  Virtual  to  Physical  Address  Translation 
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2.2.2.2.3  Cache  Memory  Support 

System  V/MLS  is  capable  of  supporting  an  optional  virtual  cache  plug-in  board  (on  both  the  AT&T 
3B2/500  and  3B2/600).  This  virtual  cache  (Vcache)  board  examines  the  virtual  address  passed  from 
the  CPU  to  the  MMU,  and  determines  if  the  address  is  a  valid  cache  entry.  If  valid,  the  Vcache 
performs  the  read/write  that  was  requested  by  the  CPU;  if  not  valid,  the  Vcache  allows  the  request 
to  continue  into  the  MMU.  When  the  data  is  returned  from  the  MMU  (on  read  operations),  the 
Vcache  copies  the  data  into  its  cache  for  later  use;  for  write  operations  which  are  cache  hits,  the 
cache  is  written  through  to  main  memory.  When  a  process  switch  occurs,  the  Vcache  is  flushed. 

2.2.2.2.4  Memory  Protection  Features 

The  MMU  controls  access  to  memory  segments  through  the  use  of  an  access  permission  Held  in  the 
SD.  Whenever  a  segment  descriptor  is  used  to  perform  a  translation,  the  MMU  checks  the  access 
permission  fields  of  the  SD,  the  type  of  access  being  requested  by  the  CPU,  and  the  execution  mode 
at  which  the  access  is  being  requested.  If  the  MMU  determines  that  the  access  is  not  allowed  under 
the  given  conditions,  an  access  rights  exception  occurs. 

The  MMU  uses  the  execution  mode  (kernel,  executive,  supervisor,  or  user)  at  which  the  access  is 
being  requested  and  the  access  permission  field  of  the  SD  to  determine  whether  access  is  allowed. 
Allowable  permissions  are  read /write /execute  (RWE),  execute  only  (EO),  read  execute  (RE),  or  no 
access  (NA)  permission  to  the  segment.  A  segment  has  four  sets  of  permissions,  one  for  each 
execution  mode.  All  processes  executing  in  a  given  execution  mode  receive  the  same  access  to  any 
given  segment.  The  hardware  prevents  a  process  fiom  operating  in  either  supervisor  or  executive 
mode,  so  the  permissions  for  these  two  modes  are  never  used. 

Associated  with  each  physical  memory  page  is  a  'page  modified'  bit  which  indicates  whether  the 
page  has  been  written  to  since  last  brought  into  memory.  If  this  bit  is  set,  then  when  the  page  is 
deallocated,  it  will  be  written  to  secondary  storage. 

2.2.2.3  Input/Output  Subsystem 

System  V/MLS  supports  many  devices  in  its  standard  and  optional  configurations:  these  include 
floppy  disk  drives,  fixed  (hard)  disk  drives,  cartridge  tape  drives,  and  a  printer.  Access  to  these 
devices  by  the  system  (or  users  of  the  system)  occurs  via  several  system  interfaces.  These  interfaces 
are  indirectly  responsible  for  maintaining  separation  of  information  between  multiple  users,  as 
explained  below. 

The  interface  to  an  external  device  consists  of  two  piec^:  the  I/O  bus  of  the  system  and  the  plug-in 
interface  card.  The  I/O  bus  provides  power  and  signal  connections  for  the  plug-in  cards  and  simply 
provides  a  means  by  which  information  is  transferred  between  the  CPU  and  external  devices  (via 
the  interface  card).  Interface  cards  are  more  complex  since  they  often  support  multiple  devices  and 
must  be  relied  upon  to  store  and  retrieve  information  irom/to  the  CPU.  Given  this  increased  logic 
necessary  on  the  interface  card,  we  have  examined  the  available  interface  cards  to  determine  those 
which  are  suitable  in  a  trusted  computing  environment.  An  exhaustive  list  of  components  included 
in  the  evaluated  configuration  is  available  in  Appendix  A  of  this  report. 

2.2.2.3.1  System  Interfaces 

This  section  of  the  report  discusses  the  interface  cards  available,  the  functional  aspects  of  each  card 
and  how  the  card  can  be  used  in  a  trusted  computing  environment.  Also  included  in  this  discussion 
are  plug-in  cards  that  extend  the  system’s  capabilities,  such  as  memory  extension  cards. 
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2.2.2.3.2  Ports  (CM195B)  Card  and  HiPorts  (CM195BA)  Card 

The  Expanded  I/O  Card  (also  known  as  the  Ports  card)  provides  four  separate  asynchronous  serial 
port  (RS-232C)  interfaces  and  one  parallel  port  interface.  The  maximum  throughput  of  the  Ports 
card  is  19,200  bits  per  second.  The  throughput  of  the  Ports  card  model  CM195BA  (also  known  as 
High  Performance  Ports  card)  is  38.4  bits  per  second. 

The  two  models  differ  in  their  internal  operation,  with  the  CM195BA  being  capable  of  performing 
with  increased  efficiency. 

2.2.2.3.2.1  Iiiq>lementation 

The  Ports  card  can  be  considered  as  having  two  distinct  sections.  The  first  is  the  serial  and  parallel 
port  interfaces.  The  second  is  the  interface  to  the  I/O  bus,  the  Common  I/O  (CIO)  hardware. 

The  serial  auid  parallel  port  interfaces  are  implemented  through  the  use  of  two  Dual  Universal 
Asynchronous  Receiver/Transmitter  (DUART)  chips  and  a  CENTRONICS'  parallel  interface.  The 
DU  ART  chips  provide  four  asynchronous  serial  ports,  denoted  as  subdevices  SD0-SD3,  which  can 
operate  in  either  polled  or  interrupt  mode.  Hardware  drivers  are  used  to  interfa^  the  DUARTs  to 
modems  or  terminals,  per  RS-232C  specifications.  The  parallel  port  interface  allows  for  polled  access 
to  an  external  device  (printer).  Ports  card  firmware  handles  all  handshaking  with  the  external 
device,  and  does  not  allow  any  interrupts  from  the  device  to  be  received  by  the  system  bus. 

The  I/O  bus  interface,  known  as  the  CIO  hardware,  is  the  second  major  component  of  the  Ports 
card.  This  section  of  the  card  is  composed  of  an  INTEL  80186  processing  unit,  Signetics  82S105  I/O 
bus  controller,  several  support  registers,  on-card  RAM  and  ROM,  and  miscellaneous  support  logic. 

The  80186  processor  is  responsible  for  the  overall  activity  of  the  Ports  card.  This  includes  the  relay 
of  information  between  the  bus  controller  and  the  DUART  chips,  maintenance  of  on-chip  registers 
and  memory,  and  the  execution  of  any  'pump'  code  that  is  downloaded  from  the  system.  Pump 
code  provides  a  mechanism  by  which  the  actions  of  the  card  can  be  tailored  by  the  host  system;  that 
is,  the  card  executes  the  pumped  software  versus  the  standard  POM  code. 

The  82S105  is  the  control  interface  to  the  system  I/O  bus.  The  82S105  responds  to  three  activities: 
80186  read/write  of  main  memory,  system  board  read/write  of  the  Ports  card,  and  acknowledgement 
of  interrupts  from  the  system  board. 

The  support  registers  on  the  Ports  card  contain  information  such  as  the  Identification  Code  of  the 
card,  the  Interrupt  Vector  of  the  card,  a  128K  byte  address  range  assigned  by  the  system  unit  in 
accordance  with  its  memory  mapping,  and  control  and  status  information  of  the  Ports  card 
components. 

The  Ports  card  RAM  is  32K  bytes  in  sise,  and  accessible  only  by  the  80186.  This  storage  area 
contains  any  downloaded  code  from  the  system  unit  and  any  locally  stored  variables.  The  ROM  is 
16K  bytes  in  sise  and  contains  the  firmware  executed  by  the  80186.  It  is  this  firmware  that  provides 
the  basic  capabilities  and  diagnostics  of  the  Ports  card. 
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A  few  routine  diagnostic  tests  are  run  for  the  Ports  card  each  time  the  3B2  computer  is  powered  up. 
A  complete  set  of  diagnostics  can  also  be  requested  through  the  use  of  the  diagnostics  monitor 
(DGMON).  Potential  problems  that  are  identified  by  the  diagnostics  routines  include:  defective 
Ports  card,  defective  I/O  bus  slot,  defective  system  board,  or  defective  diagnostic  code,  among 
others. 

2.2.2.3.2.2  Use  in  a  Trusted  Environment 

The  Ports  card  maintains  separation  between  each  serial  port  and  the  pai-allel  port,  ensuring  that  no 
data  will  be  compromised.  The  logic  within  the  card  is  designed  to  simply  forward  information 
between  the  system  unit  and  peripheral  device.  The  objective  of  this  design  is  to  ensure  that  any 
security  related  control  sequences  (such  as  trusted  path)  will  be  passed  to  the  system  unit  for 
processing.  The  team  has  verified  this  through  testing. 

2.2.2.3.3  EPorta  Card  -  CM19SY 

The  Enhanced  I/O  Card  (also  known  as  the  EPorts  card)  provides  eight  separate  asynchronous 
serial  port  (RS1.232C)  interfaces.  The  EPorts  card  provides  the  same  features  as  the  Ports  card 
(with  the  exception  of  the  parallel  port)  with  higher  throughput  (38,400  bits  per  second)  and 
hardware  flow  control. 

EPorts  suppiM'ts  the  standard  software  flow  control,  as  well  as  two  methods  of  hardware  flow 
control.  In  one  method,  the  receiving  device  must  use  the  Request  To  Send  (RTS)  and  Clear  To 
Send  (CTS)  signals  for  flow  control.  In  the  other  method,  the  receiving  device  must  use  the  Data 
Terminal  Ready  (DTR)  signal. 

2.2.2.3.3.1  Inqilementation 

The  EPorts  card  is  identical  to  the  Ports  card  in  its  support  of  the  eight  asynchronous  serial  ports. 
See  page  12,  'Implementation'  for  a  detailed  discussion  of  the  implementation. 

2.2.2.3.3.2  Use  in  a  Trusted  Environment 

The  EPorts  card  maintains  separation  between  each  serial  port,  ensuring  that  no  data  wiU  be 
compromised.  The  logic  within  the  card  is  designed  to  simply  forward  information  between  the 
system  unit  and  peripheral  device.  This  design  is  intended  to  eiiture  that  any  security  related 
control  sequences  (such  as  trusted  path)  will  be  passed  to  the  system  unit  for  processing.  The  team 
has  verified  this  through  testing. 

2.2.2.3.4  SCSI  Host  Adapter  -  CMmW 

The  Small  Computer  System  Interface  (SCSI)  Host  Adapter  Card  provides  an  asynchronous,  single- 
ended  SCSI  bus  interface.  The  bus  interface  is  capable  of  supporting  up  to  seven  peripheral 
controllers.  The  3B2  computer  can  support  up  to  eight  SCSI  Host  Adapters  simultaneously. 

2.2.3.3.4.1  ImplementatioBi 

The  SCSI  Host  Adapter  card  can  be  considered  as  having  two  distinct  sections.  The  first  is  the 
SCSI  protocol  controller.  The  second  is  the  interface  to  the  I/O  bus,  the  CIO  hardware,  as  discussed 
previously. 
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The  SCSI  protocol  architecture  can  be  viewed  as  consisting  of  four  protocol  levels: 


Level  0  - 


Level  1  - 


Level  2  - 


Level  3  - 


is  the  electrical  interface  and  signaling  protocol  defined  in  the  ANSI 
specification.  This  level  is  implemented  in  hardware,  under  the 
control  of  the  Host  Adapter  firmware. 

is  the  message  system  that  the  Host  Adapters  and  controllers  use  to 
communicate.  It  is  used  to  transfer  information  about  the  bus, 
controller,  and  request  status  under  control  of  the  firmware  in  the 
Host  Adapter  and  controllers. 

is  defined  as  the  SCSI  command  level,  to  provide  a  means  to  direct 
the  controller’s  activity. 

is  defined  as  the  user  interface  to  the  target  drivers.  Examples  of  this 
level  include  user  requests  such  as  read,  ioetl,  etc. 


Levels  0  and  1  are  implemented  within  the  SCSI  Host  Adapter  through  the  on-card  NCR  6386  SCSI 
Protocol  Control  Chip  (SPCC).  The  SPCC  is  controlled  by  an  INTEL  80186,  part  of  the  CIO 
hardware,  which  regulates  data  flow  between  the  I/O  bus  and  the  SPCC,  and  ultimately  controls 
flow  to  external  peripheral  devices. 

The  SPCC  is  responsible  for  translating  data  between  the  CIO  expected  format  and  the  SCSI  bus 
format.  This  translation  occurs  at  the  request  of  the  80186,  via  CIO  initiated  requests  and  in 
response  to  interrupts  from  peripheral  devices. 

The  SCSI  Host  Adapter  is  capable  of  receiving  software  from  the  host  system,  and  executing  that 
software  within  the  80186.  Use  of  the  SCSI  Host  Adapter  in  this  manner  allows  the  system  to  be 
customised  according  to  the  conHguration  of  peripherals. 

The  SPCC  is  supported  by  several  status  registers,  which  are  used  to  indicate  the  status  of  the  SCSI 
card,  transactions,  and  interrupts. 

The  SCSI  Host  Adapter  has  three  basic  types  of  diagnostics  available.  The  SCSI  Host  Adapter 
performs  diagnostics  during  power-up,  system  boot,  and  at  the  request  of  the  system  administrator. 
The  diagnostics  performed  basically  determine  that  the  SCSI  Host  Adapter  operation  is  functionally 
correct. 

2.2.2.3.4.2  Use  in  a  Trnsted  Enviromnent 

The  SCSI  Host  Adapter  maintains  separation  between  the  devices  connected  to  its  bus.  This 
separation  ensures  that  no  data  will  be  transferred  to  the  wrong  peripheral.  The  logic  within  the 
card  is  designed  to  forward  data  between  the  system  unit  and  peripheral  devices.  It  is  the 
responsibility  of  the  system  unit  to  specify  which  device  is  to  receive  the  data  and  to  store  any 
sensitivity  label  information  with  the  data.  The  team  has  tested  this  unit  to  provide  assurance  that 
it  is  capable  of  appropriately  separating  data  between  peripheral  devices. 

2.2.2.3.5  Memory  Extensions 

The  3B2  computer  supports  several  memory  extension  cards;  the  cards  available  are:  2M  byte  - 
CM523B,  4M  byte  -  CM523A,  and  16M  byte  -  CM523D.  These  cards  provide  an  extension  of  the 
random  access  memory  used  by  the  system,  thus  allowing  increased  system  performance.  Each  of 
these  cards  contains  32-bit  RAM  with  12-bit  Error  Correction  Codes,  capable  of  detecting  all  two-bit 
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errors  and  detecting  and  correcting  all  one-bit  errors. 

The  memory  cards  indicated  above  are  controlled  and  maintained  by  the  operating  system  of  the 
computer,  and  are  trusted  to  maintain  the  integrity  of  the  data  which  is  stored  within  the  card. 

2.2.2.3.6  Virtual  Cache  Board  -  CMS22A 

The  Virtual  Cache  (Vcache)  Board  is  used  to  provide  a  virtual  cache  environment  for  the  system 
unit.  See  the  discussion  on  page  11,  'Cache  Memory  Support'  for  additional  detail. 

2.2.2.5.7  Interface  Cards  not  in  Evaluated  Configaration 

The  following  components  were  not  configured  into  the  system  which  the  team  evaluated.  As  such, 
they  are  excluded  from  the  evaluated  configuration. 

2.2.2.3.7.1  Coprocessor  Board  -  CM627A 

The  Coprocessor  Board  utilises  the  WE  32100  microprocessor  to  provide  coprocessing  assistance  to 
the  system  unit.  Coprocessing  systems  may  present  additional  obstacles  to  implementation  of  a 
trusted  system,  and  the  vendor  has  chosen  not  to  submit  this  coprocessing  package  to  the  team  as 
part  of  the  evaluated  configuration.  As  such,  the  Coprocessor  Board  is  not  considered  an  option  for 
use  in  a  trusted  computing  environment,  and  not  included  as  an  acceptable  feature  card  for  the 
System  V/MLS  system  in  its  evaluated  configuration. 

2.2.2.3.7.2  Netwai^  Interface  Card  •  CM195A 

The  Network  Interface  Card  is  used  to  connect  the  3B2  computer  to  other  3B2  computers  and 
ETHERNET^  compatible  interfaces.  The  functionality  provided  by  the  Network  Interface  Card  is 
such  that  all  computer  systems  with  access  to  the  transmission  cable  are  capable  of  accessing  any 
data  which  is  transmitted  on  the  network.  The  Network  Interface  Card  is  not  capable  of  ensuring 
that  sensitivity  labels  associated  with  data  will  be  maintained  during  transmission.  From  a  security 
standpoint,  this  functionality  is  unacceptable  and  prevents  the  Network  Interface  Card  from  being 
considered  an  option  for  use  within  a  trusted  computing  environment. 

2.2.2.3.7.3  Network  Access  Unit  -  CM196U 

The  Network  Access  Unit  is  used  to  connect  the  3B2  computer  to  an  AT&T  STARLAN  Network. 
The  functionality  provided  by  the  Network  Access  Unit  b  such  that  all  computer  systems  with 
access  to  the  transmission  cable  are  capable  of  accessing  any  data  which  is  transmitted  on  the 
netwOTk.  The  Network  Access  Unit  is  not  capable  of  ensuring  that  sensitivity  labels  associated  with 
data  will  be  maintained  during  transmission.  From  a  security  standpoint,  this  functionality  is 
unacceptable  and  prevents  the  Network  Access  Card  from  being  considered  an  option  for  use  within 
a  trusted  computing  environment. 

2.2.2.3.7.4  Remote  Management  Package/Alarm  Interface  Cfarcnit  -  CM195AA 

The  Alarm  Interface  Circuit  (AIC)  card  is  designed  to  provide  an  interface  between  the  3B2 
computer  and  certain  external  devices,  and  to  allow  three  different  specific  functions;  allow  for  a 
remote  console  terminal;  generate  external  alarms  when  the  system’s  sanity  has  f^ed;  and  provide 
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panic  alarm  capability,  via  an  interface  to  other  external  devices.  Of  these  functions, 
implementation  of  the  first  would  invalidate  the  system’s  rating  by  providing  for  an  extension  of  the 
TCB  hardware  outside  of  the  protective  perimeter  in  which  the  CPU  and  peripherals  reside.  The 
other  two  are  ineffective  unless  the  AIC  is  connected  to  some  monitoring  device  external  to  the 
machine.  In  the  latter  case,  the  monitoring  equipment  would  not  have  been  evaluated,  and  as  such, 
cannot  be  trusted  not  to  violate  the  system’s  security  policy.  Thus,  the  Alarm  Interface  Circuit 
board  may  not  be  considered  an  option  for  use  within  a  trusted  computing  environment. 

2.2.Z.S.8  Input /Output  Devices 

As  with  most  machines,  the  3B2  computer  relies  upon  external  peripherals  to  perform  useful 
services.  Peripherals  such  as  fixed  disks,  floppy  disks  and  tapes  are  widely  used  in  the  3B2 
computing  environment.  The  previous  discussion  regarding  I/O  device  interfaces,  discussed  the 
mechanism  by  which  external  peripherals  can  be  connected  to  the  3B2.  See  Appendix  A  for  a  list  of 
devices  which  may  be  connected  to  the  system,  and  trusted  to  maintain  the  integrity  of  the  data 
that  flows  through  or  into  the  device. 

It  should  be  noted  that  the  system  must  have  a  'console',  which  is  a  terminal  plugged  into  a  special 
port  reserved  for  that  purpose  on  the  system  board.  The  console  functionality  is  the  same  as  all 
other  terminals  on  the  system  (all  users  must  login  to  access  the  system),  except  that  some  system 
software  directs  error  messages  and  notification  of  significant  events  to  the  console.  Often  a  printer 
is  connected  in  parallel  with  the  console,  to  generate  a  hardcopy  of  these  messages. 

2.2.3  The  630  MTG  InteUigent  Termina] 

The  evaluated  configuration  of  System  V/MLS  includes  an  intelligent  terminal,  the  630  MTG 
(Multi-Tasking  Graphics)  terminal,  which  can  be  used  as  a  user’s  terminal.  The  630  MTG  terminal 
provides  capabilities  that  include: 

—  the  ability  to  scroll, 

—  the  ability  to  save  text  in  any  window, 

—  the  ability  to  cut /paste/send  text  from  one  window  to  another,  and 

—  the  ability  to  attach  up  to  two  System  V/MLS  hosts. 

The  terminal  firmware  demultiplexes  the  communications  from  each  host,  passing  the  data  to  the 
terminal  resident  program  (wproc)  controlling  each  individual  window.  This  is  accomplished  on  the 
630  MTG  side  of  the  physical  port  by  a  demultiplexer/controller,  demux,  which  receives  the 
communications  from  the  host.  There  is  one  demux  per  physical  port.  Data  intended  for  a  given 
host  window  is  simply  passed  to  that  window’s  rvproe  while  control  information  (i.e.,  download 
initiation  signal)  is  handled  directly  by  demux.  More  information  on  wproc  will  be  found  on  page  74, 
'wproc'.  The  terminal  firmware  also  interprets  commands  to  create,  delete,  move,  and  reshape 
windows,  and  manages  other  terminal  capabilities  such  as  cut/paste. 

There  are  a  number  of  security-relevant  aspects  to  such  a  device.  The  following  description  of  the 
implementation  of  the  630  MTG  terminal  provides  an  outline  of  those  issues. 

The  630  MTG  contains  a  Motorola  68000  microprocessor  and  640K  bytes  of  dynamic  RAM 
(expandable  to  IM  byte).  The  630  MTG  also  contains  384K  bytes  of  EPROM,  with  a  cartridge 
port  on  the  side  of  the  unit  allowing  an  additional  384K  bytes  of  EPROM  to  be  plugged  in.  There  is 
no  memory  management  or  paging  functionality  implemented  in  the  terminal  hardware.  The  video 
display  is  bitmapped,  with  a  resolution  of  1,024  x  1,024  pixels.  The  terminal  incorporates  two  RS- 
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232  ports  for  communications  with  one  or  more  hosts.  The  terminal  supports  a  printer  which  is 
disabled  in  the  evaluated  configuration,  since  its  output  would  not  be  labeled  according  to  the 
labeling  requirements^.  The  terminal  also  supports  a  mouse  for  easy  manipulation  of  the  terminal’s 
many  features. 

The  terminal  runs  a  trusted  version  of  the  standard  630  MTG  terminal  emulator  firmware,  which 
implements  a  trusted  communications  path  between  the  user  and  the  host  computer  in  addition  to 
providing  labeling,  mandatory  access  control,  and  preventing  object  reuse  in  accordance  with  the  Bl 
requirements.  Communication  between  the  terminal  and  the  trusted  host  software  takes  place  via 
one  of  the  16  virtual  terminal  connections,  8  virtual  terminal  connections  (channels)  per  host,  which 
the  630  MTG  terminal  is  capable  of  supporting.  AU  control  communication,  such  as  setting  up  and 
labeling  windows,  is  carried  by  channel  0  (virtual  terminal  device  0,  referred  to  as  'xtnmO',  where  n 
and  m  are  digits  used  for  terminal  identification  only,  and  will  henceforth  be  omitted).  User 
Mrindows  may  occupy  channels  xtl  through  xt7  on  each  host  connection.  The  control  window,  xtO, 
is  invisible  to  the  user. 

The  host  device  driver  (xt  driver),  which  communicates  directly  (sends  data  over  the  physical 
connection)  with  the  630  MTG  terminal,  ensures  data  separation  at  the  virtual  terminal  level,  much 
as  ports  ensure  data  separation  at  the  physical  terminal  level.  The  details  on  how  this  is 
accomplished  are  described  on  page  74,  'Window  Labels'. 

The  630  MTG  does  not  provide  memory  management  within  its  local  address  space,  so  no  program 
which  is  untrusted  may  be  downloaded  and  run  on  the  630  MTG  without  invalidating  the  system’s 
rating.  For  this  reason,  it  is  only  possible  to  download  code  from  the  directory  /uar/dmd/bin,  in 
which  only  trusted  code  resides.  Downloading  may  only  occur  through  the  action  of 
/nsr/bin/dmdld,  which  is  hard>coded  such  that  it  will  only  download  programs  from  that  directory 
(see  page  78,  'Downloadable  Software').  The  evaluated  configuration  includes  two  such  programs; 
fw.mods  and  chk6S0.  These  are  explained  on  page  72,  'The  630init  Process'. 

There  are  four  major  630  MTG  firmware  components: 

•  System  -  contains  the  round-robin  scheduler,  system  initialization  logic  and  system 
processes  that  handle  global  mouse  interaction,  window  manipulation,  key  translation 
and  host  I/O  multiplexing. 

•  Application  -  contains  application  level  processes  that  perform  terminal  emulation, 
set  the  terminal  characteristics  and  program  the  programmable  function  keys. 

•  xt  protocol  -  implements  a  communication  protocol  between  the  host  and  630  MTG. 
This  is  the  protocol  used  in  the  layers  environment. 

•  Libraries  -  contains  routines  used  by  firmware  components  and  downloaded 
programs.  The  library  routines  are  accessed  through  the  firmware  vector  table, 
which  is  a  table  containing  addresses  of  functions  and  global  variables  which  are 
indirectly  called  and  accessed  by  the  630  MTG.  The  firmware  vector  table  is  located 


3.  Physical  security  is  relied  upon  to  prevent  the  printer  from  being  enabled  after  the  initial  630  MTG  terminal  session 
connection  with  the  host  is  made.  The  printer  is  initially  assured  to  be  disal)led  as  part  of  the  terminal  initialiration 
process. 
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after  the  exception  vector  table  in  RAM  and  is  located  before  a  4K  byte  pad  area 
which  exists  in  case  the  vector  table  (or  ROM  bss,  which  is  on  the  other  side  of  the 
pad  area)  needs  to  be  extended. 

2.2.3.1  630  MTG  Memory  Layomt 

The  630  MTG  does  not  support  virtual  addressing  and  has  no  memory  protection  except  that 
provided  by  using  ROM  to  hold  the  terminal  firmware.  The  630  MTG  memory  is  displayed  as: 


Revision  10.4 


-  18- 

overview.mm 


(Revised  5/24/91) 


Final  Evaluation  Report  ATAT  Systen  V/NL8 

Systea  Overview 


000000 


100000 

200000 

400000 

700000 

760000 

780000 


800000 

FE£001 

Figore  1.  The  630  MTG  Memory  Layout. 
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Figure  2  from  top  to  bottom  describes  the  memory  layout  of  the  630  MTG.  The  first  item  in  low 
memory  is  the  table  of  interrupt/exception  vectors.  These  interrupt  vector  entries  point  to  the 
interrupt  vector  table  in  RAM.  The  RAM  interrupt  vector  table  entries  contain  jump  instructions 
to  the  real  interrupt/exception  handlers  in  ROM.  Following  the  interrupt /exception  table  is  the 
firmware  vector  table  which  gets  moved  to  RAM  with  initialized  data  structures  on  reboot.  All 
firmware  function  calls  go  through  the  RAM  table,  whereas  interrupts/exceptions  go  through  both 
tables.  Following  both  these  ROM  vector  tables  are  the  text  and  data  sections  of  the  firmware. 
These  are  the  components  of  the  standard  EPROM. 

Video  RAM  is  dual  ported  so  that  video  control  and  CPU  processing  can  proceed  simultaneously. 
Following  the  video  RAM  are  the  RAM  interrupt /exception  vector  table  (pointing  to  ROM  located 
handlers)  and  the  RAM  firmware  vector  table  (pointing  to  ROM  located  firmware  routines).  The 
pad  area  exists  so  that  the  firmware  can  be  modified  and  thus  grow  in  size. 

The  Non-Volatile  Read-Access  Memory  (NVRAM)  is  battery  backed  and  holds  terminal  setup  data 
and  the  character  strings  associated  with  the  progranunable  function  keys. 

2.2.3.2  630  MTG  Memory  Management 

The  630  MTG  performs  memory  management  through  its  firmware;  there  is  no  special  hardware  to 
manage  memory.  The  main  tasks  in  managing  memory  on  the  630  MTG  are  to  save  and  retrieve 
portions  of  windows  which  may  become  obscured  by  other  overlapping  windows,  and  to  support  the 
downloading  functionality. 

There  are  three  types  of  memory,  which  are  illustrated  in  Figure  3:  memory  blocks  obtained  from  an 
alloc  pool,  a  gcalloc  pool  and  a  combination  of  the  two  called  a  gcastray  block. 
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Memory  allocated  with  alloc  starts  at  the  low  end  of  user  memory  space  and  grows  upward  in 
memory.  It  is  non-compactible  and  is  therefore  limited  by  some  upper  bound  stored  in  the  variable 
alloclimit.  Alloc  employs  a  Hrst-fit  algorithm,  combining  contiguous  free  blocks.  Alloc  zeros  out  the 
requested  memory  (i.e.,  fills  with  zeros).  Blocks  cannot  be  allocated  with  alloc  past  alloclimit  or 
beyond  the  first  block  allocated  via  gcalloc  encountered  by  alloc  (the  gclevel).  Memory  allocated  via 
alloc  is  used  for  downloads,  thread  stacks,  window  structures,  PFkeys,  and  other  general  dynamic 
storage  (identiHed  on  page  71,  'The  630  MTG  Terminal  Implementation). 

Gcalloc  stands  for  garbage  collectable  allocated  memory.  Memory  allocated  via  gcalloc  starts  from 
the  high  end  of  user  memory  space  and  grows  downward  in  memory  to  the  alloclevel  boundary  and 
is  compactible.  Gcalloc  allocates  blocks  from  the  lower  level  of  the  pool  (i.e.,  it  lowers  gclevel).  If 
there  is  not  enough  space  at  the  low  end  of  the  pool  (i.e.,  if  it  reaches  alloclevel),  the  pool  is 
compacted  towards  its  upper  boundary.  Memory  allocated  via  gcalloc  is  primarily  used  to  store  lines 
of  text  in  windows. 

Gcalloc  allocates  blocks  in  the  alloc  pool  when  there  is  not  enough  space  in  the  gcalloc  pool  after 
compaction  to  satisfy  a  request.  A  block  allocated  this  way  is  referred  to  as  a  gcattray  block. 

2.2.3.3  Use  in  a  Trosted  Environment 

The  630  MTG  terminal  allows  a  user  to  work  with  multiple  terminal  sessions  operating  at  various 
labels  connected  to  one  or  two  hosts.  Only  one  user  login  session  per  host  is  active,  although  many 
host  connected  and  local  windows  can  be  active  at  any  time.  The  630  MTG  provides  an  interface 
which  appears  as  a  complete  and  independent  terminal  device  to  each  host  process  connected  to  the 
terminal.  In  order  to  implement  this  functionality,  the  terminal  firmware  partitions  the  terminal 
memory  to  support  up  to  eight  per  host  windows  (seven  windows  accessible  to  the  user;  one  for 
control  information). 

When  using  both  physical  ports  on  the  630  MTG  terminal,  it  is  required  that  the  accredition  ranges 
of  both  hosts  be  identical.  This  is  required  because  the  overall  rating  of  System  V/MLS  is  Bl,  and 
the  combination  of  two  System  V/MLS  systems  connected  via  the  630  MTG  terminal  must  also  be 
considered  a  Bl  system^. 

Additionally,  the  administrators  on  both  systems  should  coordinate  any  decisions  regarding 
downloadable  software.  Any  software  downloaded  into  the  630  MTG  terminal  can  affect  the  trusted 
capabilities  of  the  630  MTG  terminal. 

Although  the  evaluated  configuration  of  the  630  MTG  terminal  does  not  incorporate  all  of  the 
functionality  of  the  stock  630  MTG,  it  still  retains  a  wide  variety  of  useful  capabilities  unique  among 
the  systems  evaluated  to  date. 

2.2.4  Physical  Security  Considerations 

The  AT&T  3B2/500  and  3B2/600  computers,  on  which  System  V/MLS  runs,  have  physical 
dimensions  which  are  small  enough  so  that  the  entirety  of  the  TCB  hardware  could  easily  fit  on  or 
under  a  desk  in  the  average  office.  Because  of  this  small  size,  it  is  especially  important  to  note  here 
that  there  are  certain  physical  security  considerations  involved  in  appropriate  deployment  of  any 


4.  When  acrrcditiiif  a  system  witb  multiple  hosts  and  multiple  630  MTG  terminals,  rare  should  be  taken  to  place  no  more 
trust  in  the  data  separation  capabilities  of  the  630  MTG  terminal  than  that  afforded  by  a  Bl  system. 
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computer  system  which  is  expected  to  process  sensitive  information. 

Primarily,  the  system  administrator  must  understand  that  any  computer  relies  upon  its  physical 
security  as  a  basis  for  all  other  security  which  it  provides.  A  computer  which  is  left  unattended  and 
unprotected  in  the  presence  of  untrusted  individuads  is  liable  to  be  tamjtered  with;  therefore,  the 
system  administrator  should  take  precautions  that  all  elements  of  the  TCB  hardware  are  protected 
in  a  fashion  appropriate  for  the  most  sensitive  information  on  the  system.  The  single  exception  to 
this  rule  is  that  remote  devices,  such  as  terminals  and  printers,  should  be  protected  as  appropriate 
for  the  most  sensitive  information  which  they  are  capable  of  accessing.  For  example,  a  terminal  may 
have  a  device  maximum  of  SECRET,  alth&ugh  the  system  high  is  TOP  SECRET;  in  this  case,  the 
terminal  should  be  protected  as  though  it  is  SECRET  information. 

2.2.4.1  The  Firmware  Password  and  The  Floppy  Key 

As  an  additional  security  enhancement,  the  3B2/50Q  and  3B2/600  computers  require  a  password 
before  allowing  access  to  'Grmware  mode',  from  which  system  diagnostics  and  other  low-level 
functions  (including  selection  of  bootstrap  load  device)  may  be  accessed. 

Since  use  of  the  flrmware  password  is  likely  to  be  an  infrequent  event,  it  is  quite  possible  that  the 
83r8tem  administrator  may  forget  the  firmware  password.  To  remedy  this  problem,  the  3B2/500  and 
3B2/600  come  with  a  device  referred  to  as  the  "Floppy  Key."  This  is  a  floppy  diskette  which  is 
keyed  to  the  serial  number  of  the  particular  3B2  computer  on  which  it  was  generated.  The  Floppy 
Key  is  meant  to  be  used  in  one  of  two  cases:  either  the  root  or  firmware  password  is  lost,  or  the 
system  battery  is  weak  and  parts  of  the  system  Non-Volatile  RAM  (NVRAM)  become  unreadable 
and  must  be  restored. 

The  Floppy  Key  may  be  used  to  reset  the  system  NVRAM  to  its  default  values,  and  to  gain  access 
to  the  system  in  firmware  mode.  It  is  therefore  imperative  that  the  Floppy  Key  be  afforded  the 
same  protection  that  would  be  provided  for  the  most  sensitive  data  on  the  computer  with  which  it  is 
associated. 
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2.3  Software  Architecture 

System  V/MLS  enforces  security  through  the  use  of  hardware  (as  previously  discussed)  as  well  as 
software.  The  software  of  the  system  provides  the  interface  to  the  TGB  and  is  responsible  for 
determining  access  to  the  objects  controlled  by  the  system.  The  following  is  a  discussion  of  the 
system  software  architecture  and  the  mechanisms  provided  within  the  kernel. 

2.3.1  TCB  Boundary 

First  it  is  important  to  note  the  boundary  of  the  TGB.  The  TGB  is  made  up  of  hardware,  firmware, 
and  software  components.  Hardware  and  firmware  comimnents  were  discussed  previously  on  page  4, 
'Hardware  Architecture'  and  on  page  16,  'The  630  MTG  Intelligent  Terminal'.  Software 
coiiiponents  consist  of  all  trusted  routines.  Trusted  routines  are  aU  routines  running  in  kernel  space 
(including  630  MTG  terminal  routines)  as  well  as  trusted  processes  running  in  user  space.  The 
system’s  kernel  contmns  those  routines  running  in  kernel  space  and  are  listed  in  Appendix  B. 
Trusted  processes  are  defined  on  page  63,  'Trusted  Processes',  and  are  listed  as  part  of  Appendix  G. 
The  kernel,  trusted  processes,  and  630  MTG  terminal  will  now  be  discussed. 

2.3.2  Kernel  Architecture 

2.3.2.1  Overview 

The  System  V/MLS  software  architecture  can  be  viewed  as  a  series  of  conceptual  layers.  It  is 
important  to  note  that  the  term  'layer'  as  used  in  this  sense  throughout  this  section  is  in  no  way  to 
be  confused  with  the  system  engineering  technique  'layering'  that  can  be  found  in  the  design  of 
higher  level  TGSEG  systems.  The  innermoet  layer  is  the  system  hardware,  followed  by  the  kernel 
routines  and  system  commands.  User  programs  may  then  logically  be  viewed  as  being  built  upon 
the  system  commands  and  kernel  interface,  in  the  outermost  layer. 

2.3.2.2  Hardware  Layer 

System  V/MLS  takes  advantage  of  the  processing  modes  provided  by  the  hardware  layer  (see  page 
4,  'Hardware  Architecture*)  to  provide  isolation  between  the  system  and  user  spaces.  The  two 
execution  modes  used  by  the  system  are; 

User  mode:  Processes  in  user  mode  can  access  their  own  instructions  and  data  but 

not  privileged  instructioas  and  data  (or  those  ot  other  processes). 
Execution  of  privileged  instructions  results  in  an  error.  . 

Kernel  mode;  Processes  are  permitted  the  execution  of  :‘J1  system  instructions  and 

can  access  kernel  and  user  addresses. 

2.3.2.3  Kernel  Layer 

The  kernel  layer  provides  the  system  call  interface  between  user  programs  and  the  TGB.  The  kernel 
performs  various  primitive  operations  on  behalf  of  user  processes  to  support  the  user  interface 
described  below.  Among  the  services  provided  by  the  kernel  are: 

—  Gontrolling  the  execution  processes  by  allowing  their  creation,  termination  or 
suspension,  and  interprocess  communication. 

—  Scheduling  processes  fairly  for  execution  on  the  GPU. 

—  Allocating  main  memcny  for  processes. 
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—  Allocating  secondary  storage  for  long  term  data  storage. 

—  Allowing  processes  controlled  access  to  peripheral  devices  such  as  terminals,  tape 
drives  and  disk  drives. 

The  kernel  provides  its  services  transparently  for  the  user.  When  a  process  executes  a  system  call, 
the  execution  mode  of  the  process  changes  from  user  mode  to  kernel  mode,  and  the  operating  system 
executes  and  attempts  to  service  the  user  request. 

2.5.2.3.1  Scheduling: 

Processes  share  the  GPU  in  a  time-shared  manner,  meaning  each  process  is  allowed  up  to  one  second 
of  execution  time  at  any  one  time.  If  a  process  h^>pens  to  be  in  the  middle  of  a  system  call  at  the 
one  second  interval,  then  that  process  is  permitted  to  finish  the  system  call  before  it  is  preempted. 
Processes  are  also  preempted  when  they  request  a  time  consuming  task,  such  as  physical  I/O,  or  are 
waiting  on  a  synchronisation  event. 

Once  the  current  process  has  been  preempted,  the  process  with  the  highest  priority  is  chosen  from 
the  ready  queue  to  run  next.  Processes  are  given  a  primity  based  upon  a  compute  time/elapsed  time 
ratio  and  a  fixed  priority  class.  For  example,  system  processes  are  given  a  higher  priority  class  than 
user  processes.  Processes  at  the  same  priority  are  effectively  executed  in  a  round-robin  fashion. 

2.3.2.3.2  Memory  AUocation: 

The  kernel  and  aU  user  processes  operate  m  virtual  address  space.  The  hardware  divides  the  virtual 
address  space  into  physical  pieces  called  pages.  Each  of  the  four  sections  of  virtual  address  space  is 
composed  of  segments  which  are  in  turn  composed  of  pages.  Regions  are  the  logical  representatbn 
of  pieces  of  virtual  address  space  as  viewed  by  the  system  software.  Data  tables  are  maintained  by 
the  kernel  to  provide  virtual  to  physical  address  translation. 

As  stated  previously,  there  are  four  sections  cS  virtual  memory,  each  one  having  a  separate  segment 
descriptor  table  (SDT).  The  SDTs  are  located  in  physical  memory  and  contain  the  segment 
descriptors  (SDs).  Each  segment  has  one  page  descriptor  table  (PDT)  which  contains  its  page 
descriptors  (PDs).  Segments  are  thus  represented  by  both  a  SDT  entry  and  an  entire  PDT. 

System  V/MLS  manages  memory  by  maintaining  regions  fm  each  process.  The  regions  allocated  to 
a  process  define  the  memory  space  that  the  process  can  use  during  its  lifetime.  Every  process  has  a 
pointer  (through  its  process  table  entry,  see  page  30,  'Process  Table')  to  a  data  structure  known  as 
a  process  region  (pregion)  table.  At  system  start  up  time,  memory  is  allocated  for  the  pregion 
tables,  and  a  pregion  table  is  associated  with  each  process  slot  in  the  process  table.  Pregion  entries 
contain  informatbn  about  the  connection  of  a  region  to  a  process.  Pregion  entries  map  to  region 
table  entries  which  contain  a  list  of  SDs.  These  SDs  point  to  page  tables  which  map  to  physical 
pages  f<»-  the  region.  This  list  of  SDs  is  called  an  rlist.  The  system  region  table  (region  table) 
contains  entries  fm  all  active  regions  on  the  system.  The  region  table  entries  contain  all  the 
information  needed  to  attach  a  region  to  a  process.  The  translation  from  virtual  to  physical  address 
is  performed  within  the  hardware  (see  page  8,  'Address  TVanslation  Mechanism')  using  this 
infmmation.  When  a  process  u  created,  it  has  two  SDTs  associated  with  it  (as  there  are  two  SDTs 
which  map  user  address  space),  as  part  of  the  process  structure.  The  SDT  is  a  one  to  one  mapping 
to  an  rlist  of  an  attached  region.  When  a  process  becomes  active,  the  rlists  for  the  attached  regions 
are  loaded  into  the  appropriate  SDT  and  the  address  of  the  SDT  is  loaded  into  an  MMU  register. 
This  segment  table  information  is  then  used  in  resolving  virtual  addresses. 
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A  region  is  actually  a  virtually  contiguous  piece  of  memory  that  can  be  associated  with  some  logical 
function.  The  typical  types  of  regions  associated  with  a  process  are  text,  data  and  stack.  Two 
additional  types  of  regions,  however,  may  also  be  associated  with  a  process;  shared  memory  and 
shared  text  (e.g.  libraries). 

Shared  memory  regions  are  associated  with  a  process  through  the  utilisation  of  the  IPC  shared 
memory  mechanism  known  as  'shared  memory  segments'.  The  shared  memory  IPC  mechanism 
provides  system  calls  to  facilitate  the  use  of  regions  in  a  shared  manner.  The  shmget  system  call 
creates  a  shared  memory  region  by  allocating  a  region  data  structure  and  placing  a  pointer  to  the 
region  table  entry  in  a  table  known  as  the  shared  memory  table.  The  shared  memory  region  is 
attached  to  the  virtual  address  space  of  the  process  through  the  ahmat  system  call  by  allocating  a 
pointer  from  the  pregion  table  to  the  associated  region  table  entry. 

The  sharing  occurs  when  one  or  more  processes  attach  to  the  same  shared  region.  This  is  achieved 
when  processes  call  shmat  and  provide  it  the  same  ID  (which  was  returned  by  the  shmget  call  when 
the  region  was  created).  Before  a  process  can  successfully  attach  to  a  shared  region,  however,  it 
must  have  appropriate  discretionary  access  control  }>ermissions  for  the  region.  Permission  bits  for  a 
shared  region  of  this  type  are  kept  in  its  shared  memory  table  entry.  Further  information  on  DAG 
on  shared  memory  objects  can  be  found  on  page  43,  'DAC  on  System  V  IPC  Objects'.  Once  a 
shared  memory  region  is  allocated  to  a  process,  it  becomes  part  of  the  virtual  address  space  of  the 
process  and  is  maintained  by  the  system  in  the  same  manner  as  are  other  types  of  regions. 

Shared  text  regions  are  also  maintained  in  the  same  manner  as  are  other  regions,  but  allow  for 
sharing  through  a  completely  different  method.  The  header  of  an  executable  load  module  indicates  if 
its  text  is  to  be  shared.  If  so,  the  kernel  looks  for  the  original  text  region  in  the  active  region  list 
and  if  found,  attaches  it  to  the  process.  If  a  shared  text  region  does  not  yet  exist,  a  new  region 
(created  RE)  is  attached  to  the  process. 

Memory  allocation  illustrating  the  use  of  shared  memory  and  shared  text  is  shown  in  Figure  4.  Note 
that  Process  A  and  Process  B  are  sharing  a  text  region,  and  Process  B  and  Process  C  are  sharing  a 
shared  memory  region. 

To  enhance  the  effectiveness  of  the  use  of  shared  text,  a  mechanism  known  as  the  'sticky-bit'  is 
provided.  The  sticky-bit  is  one  of  the  file  mode  bits  associated  with  every  file.  The  system 
administrator  can  set  this  bit  for  an  executable  file  through  the  chmod  system  call.  When  a  process 
executes  a  ffle  that  has  its  sticky-bit  set,  the  text  of  the  file  remains  in  memory  even  if  its  region 
reference  count  drops  to  0.  This  allows  frequently  used  text  regions  (i.e.,  shared  text)  to  remain  in 
memory  and  thus  spare  the  kernel  the  overhead  of  repeatedly  having  to  bring  shared  text  regions 
into  memory. 

Given  that  the  demand  for  memory  is  often  greater  than  the  amount  of  physical  memory  available, 
the  system  supports  page  replacement.  The  algorithm,  known  as  'least  recently  used  second  chance 
replacement',  provides  for  a  fair  replacement  strategy.  To  implement  this  algorithm,  two  bits  are 
needed:  that  the  page  has  been  referenced  by  a  process.  The  need  reference  bit  indicates  that  the 
page  hasn’t  been  referenced,  but  will  probably  be  referenced  soon.  When  a  page  is  aged  the  first 
time,  the  reference  bit  is  cleared  and  the  need  reference  bit  is  set.  On  the  second  aging  pass,  if  the 
reference  bit  is  clear  and  the  need  reference  bit  is  set,  then  the  need  reference  bit  is  cleared.  If  both 
bits  are  clear,  the  page  is  available  to  be  replaced. 
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2.3.2.4  Comniand  Layer 

The  command  layer  provides  a  convenient  interface  that  users  can  utilise  to  request  system  services. 
The  TCB  interface  at  the  command  layer  is  composed  of  those  commands  provided  with  System 
V/MLS,  as  described  in  Appendix  C. 

The  'shell',  /bin/sh,  is  the  System  V/MLS  security  enhanced  Bourne  shell  comm2md  interpreter. 
The  shell  is  actually  both  a  command  interpreter  and  a  programming  language.  In  either  regard,  it 
provides  an  interface  to  the  TCB  through  which  users  may  execute  system  and  user  provided 
programs  which  utilize  lower  level  system  services.  The  shell  allows  for  control-flow  primitives, 
parameter  passing,  variables  and  string  substitution  as  well  as  allowing  users  to  customize  their  own 
working  environment. 

The  shell  is  trusted  not  to  modify  the  information  provided  by  the  user  and  to  ensure  that  it  will 
invoke  the  actual  program  specified.  System  V/MLS  incorporates  two  major  changes  in  the  shell  in 
order  to  increase  its  level  of  trust.  Upon  invocation  of  a  child  shell  process,  the  sheU  will  reset  the 
effective  UID/GID  of  that  process  to  its  real  UID/GID  (for  discussion  of  the  various  process  IDs,  see 
page  30,  'Process  Data  Structures').  Additionally,  the  shell  will  enforce  that  any  shell  scripts  run 
by  root  must  be  trusted  shell  scripts.  This  is  done  by  checking  that  the  label  on  the  shell  script  is 
level  0,  SYSTEM,  (see  page  53,  'System  Software  Integrity')  before  allowing  its  execution  by  root. 

For  system  administrators,  the  command  layer  of  the  TCB  provides  many  programs  that  can  be 
used  to  configure,  maintain,  and  control  the  activities  of  the  system.  Functionality  provided  for  the 
administrator  includes  adding  users,  changing  file  ownership  information,  and  reviewing  audit  logs. 

Those  files  that  the  system  administrator  must  rely  on  to  perform  his/her  duties  are  considered  part 
of  the  TCB.  For  these  files,  one  or  more  of  the  following  are  true: 

—  the  file  runs  in  a  privileged  execution  mode;  this  occurs  when  a  file  is  SUID  or  SGID 
to  an  administrative  ID,  or  must  be  run  by  an  administrator  (see  page  63,  'Trusted 
Processes'). 

—  the  file  may  be  read  only  by  an  administrator. 

—  the  file  may  be  written  only  by  an  administrator. 

2.3.3  Filesystem 

2.3.3.1  Filesystem  Overview 

The  System  V/MLS  filesystem  is  a  secondary  storage  aUocation  and  management  system  for  regular, 
directory  and  pipe  files  (see  page  36,  'Objects').  The  kernel  allocates  secondary  storage  for  user 
files,  reclaims  unused  storage,  and  protects  user  files  from  illegal  access.  The  filesystem  has  a  tree 
structured  hierarchy.  At  the  base  of  the  tree  is  the  root  directory  (referred  to  as  '/').  Every  non¬ 
leaf  node  of  the  tree  is  a  directory  of  files,  and  files  at  the  leaf  nodes  are  either  directories,  regular 
files,  or  special  files.  Files  arc  referenced  by  a  path  name,  which  describes  the  location  of  the  file 
within  the  tree  hierarchy. 

Special  files  (also  named  pipes  and  directories)  are  created  via  the  mknod  system  call,  which  is 
similar  to  creat  in  that  an  inode  is  allocated  for  the  file.  For  special  files,  mknod  writes  a  major  and 
minor  device  number  into  the  inode.  The  user  interface  to  special  files  is  through  the  filesystem.  The 
special  file  occupies  a  position  in  the  directory  hierarchy  of  the  filesystem.  Additionally,  the  normal 
filesystem  system  calls  (e.g.,  open,  close,  read,  write)  have  an  appropriate  meaning  for  special  files. 
Files  on  System  V/MLS  do  not  assume  any  unique  structure  based  upon  their  coiitent.  All  files  are 
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stored  in  a  similar  fashion,  and  any  meaning  associated  with  the  stored  information  is  determined  by 
the  program  accessing  the  file. 

2.3.3.2  Internal  Representation 

Inodes  are  internal,  TCB  supported  storage  objects  which  are  used  to  deHne  and  maintain  filesystem 
based  objects.  The  inode  contains  information  related  to  filesystem  objects  such  as  ownership,  GID, 
owner/group/other  access  permissions,  object  size,  access  times,  and  physical  disk  addresses  for  data. 
Every  filesystem  object  has  one  inode,  but  may  have  several  names,  all  mapping  to  the  same  inode. 

Inodes  are  referenced  via  an  inode  pointer,  stored  in  a  directory.  The  directory  contains  pairs  of 
filesystem  object  names  and  inode  pointers.  This  allows  multiple  name/inode  pointer  pairs  to  refer 
to  the  same  inode,  allowing  multiple  names  for  inodes  (and  thus  files). 

2.3.4  System  Initialisation 

The  act  of  loading  the  kernel  system  image  into  memory  and  starting  its  execution  is  known  as  a 
system  boot.  System  boot  occurs  whenever  the  system  is  started  from  a  power-up,  following  system 
crashes  and  intentional  system  shutdowns. 

System  boot  occurs  in  several  phases.  In  the  first  phase,  the  computer  hardware  loads  and  executes 
the  first  block  of  data  from  the  bootstrap  disk.  This  data  block  contains  a  short  bootstrap  loader 
program  which  finds  and  loads  the  file  named  / unii  in  the  root  directory.  The  file  / unix  contains 
the  machine  instructions  for  the  operating  system  kernel,  and  its  execution  comprises  phase  two  of 
the  system  boot  procedure. 

In  phase  two,  the  kernel  initializes  the  essential  hardware  elements  of  the  system,  such  as  the  system 
clock  and  memory  management  unit.  The  kernel  also  defines  system  data  structures  which  will  be 
used  to  support  and  maintain  processes.  The  kernel  then  begins  to  create  process  0,  the  sched 
process.  Sched  is  created  by  defining  process  0  within  the  system  process  maintenance  tables. 

The  system  then  copies  process  0  to  create  process  1.  Process  1  is  expanded  in  size  and  the  machine 
instructions  to  invoke  /etc/init  are  placed  within  its  code  region.  Process  1  is  placed  in  the  CPU 
ready  queue,  and  invoked  by  the  system  scheduler. 

Upon  invocation  by  the  scheduler,  process  1  is  considered  the  inxt  process.  The  init  process  is 
responsible  for  setting  up  the  process  structure  of  the  System  V/MLS  system.  Init  creates  a  new 
process  called  getty  for  each  login  device  available  on  the  system.  Getty  waits  for  a  user  to  attempt 
to  login  at  the  terminal  port  associated  with  the  program.  During  the  time  when  init  spawns  such 
processes  allowing  users  to  login  to  the  system,  a  transfer  is  made  to  multi-user  mode.  At  this  time 
the  filesystem  is  examined  to  verify  its  correctness  (by  /etc/fsck)  and  the  system  audit  mechanism 
is  invoked  {/mls/bin/satstart). 

When  a  user  starts  to  login  to  the  system,  getty  adjusts  the  line  protocol  and  overlays  itself  with  a 
new  program,  login.  Login  checks  and  validates  the  password  provided  by  the  user.  If  the  password 
is  valid,  login  then  invokes  the  user’s  first  process.  The  first  process  is  usually  the  'shell*.  For 
further  information  regarding  the  login  process,  see  the  discussion  on  page  59,  'User  Identification 
and  Authentication*. 

2.4  TCB  Protected  Resources 
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2.4.1  Subjects 

In  System  V/MLS,  the  subjects  are  processes  which  execute  on  behalf  of  the  users.  Processes,  which 
may  be  thought  of  as  programs  in  execution,  are  composed  of  the  following  logical  sections  of  virtual 
address  space;  text,  data,  stack,  and  any  shared  memory  regions.  The  kernel  has  its  own  text,  data 
and  stack  regions.  The  system  region  table  contains  regions  for  every  active  process.  Users  cannot 
access  the  kernel  regions,  but  can  request  the  kernel  to  work  on  their  behalf  by  using  system  calls. 

2.4.1.1  Process  Data  Structures 

The  data  structures  associated  with  processes  are  the  process  table,  the  user  area,  and  the  process 
region  table.  These  tables  define  the  context  of  a  process. 

2.4.1.1.1  Process  Table 

The  process  table,  which  always  remains  memory-resident,  defines  process  information  to  the  TCB. 
Non-privileged  users  may  indirectly  modify  their  own  process  table  entry  through  the  use  of  system 
calls. 

Important  Process  Table  Fields  are: 

—  process  state 

Identibes  the  status  of  the  process  (e.g.  ready,  waiting,  running,  sleeping,  blocked) 

—  process  priority 

The  scheduler  uses  this  information  to  determine  which  process  will  be  selected  to 
run.  The  priority  is  adjusted  when  a  clock  interrupt  is  generated. 

—  real  user  ID  (RUID) 

Records  the  login  ID  number  of  the  user  responsible  for  the  process.  It  can  be 
changed  by  su.  The  real  and  effective  user  IDs  of  a  process  are  inherited  from  its 
parent. 

—  saved  user  ID 

The  effective  user  ID  number  of  the  process  at  the  time  of  program  invocation  cxtc(). 
It  can  be  changed  by  s«  and  other  setuid  to  root  programs. 

—  process  ID  (PID) 

The  TCB  assigns  a  number  which  at  any  given  time  uniquely  identifies  that  process. 
The  TCB  assigns  process  IDs  sequentially. 

—  parent  process  ID  (PPID) 

The  process  ID  of  the  parent  process. 

—  process  group  ID  (PGID) 

A  process  group  is  a  set  of  processes  sharing  the  same  control  terminal.  The  process 
group  ID  is  the  process  ID  of  the  process  from  which  all  the  other  process  group 
members  are  descendents.  The  kernel  uses  the  PGID  to  identify  a  set  of  processes 
that  should  receive  a  common  signal  for  certain  events. 

—  a  signal  field  (p_hold) 

Each  bit  position  represents  the  status  (i.e.  whether  the  process  is  or  is  not  accepting 
that  signal)  of  a  signal  for  that  process. 
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—  a  signal  field  (p_8ig) 

Each  bit  position  represents  whether  a  signal  has  been  posted  for  that  process. 

—  a  pointer  to  this  process’s  parent  process  table  entry. 

—  a  pointer  to  the  children  of  this  process 

If  a  child  dies  and  has  children  of  its  own,  then  the  children  are  inherited  by  init,  via 
the  exit  system  call. 

—  a  pointer  to  the  process  region  table  -  (see  Figure  5) 

—  a  pointer  to  the  process’s  user  area 

2.4.1.2  User  Area 

Every  process  in  the  process  table  is  allocated  a  user  area  which,  when  paged  into  memory,  is 
located  in  kernel  address  space.  User  areas  contain  information  that  the  kernel  uses  when  a  process 
is  executing.  Only  the  kernel  can  directly  access  the  user  area  of  the  executing  process. 

Important  fields  in  the  User  Area  are: 

—  pointer  to  the  process  table  -  (see  Figure  5) 

—  real  and  effective  user  IDs  -  previously  defined 

—  real  group  ED 

Identifies  the  group  associated  with  the  process. 

—  effective  group  ID 

Identifies  the  current  group  ID  associated  with  the  operating  process.  This  may  or 
may  not  be  the  same  as  the  real  group  ID  and  is  changed  via  the  setgid  mechanism 
(see  page  44,  'Setuid/Setgid  Mechanisms'  ). 

2.4.1.2  Process  Region  Table 

Each  process  region  table  (pregion  table)  is  a  table  used  during  the  mapping  of  a  process’s  virtual 
address  to  physical  address.  For  the  implementation  details,  see  page  25,  'Memory  Allocation'. 
The  kernel  accesses  the  process  region  table  to  identify  information  about  the  type  and  virtual 
address  of  a  region.  Each  process  has  its  own  process  region  table. 

The  Process  Region  Table  Entry  Fields  are; 

•  a  pointer  to  the  entry  in  the  system  region  table  (the  region’s  descriptor) 

•  the  starting  virtual  address  of  the  region 

•  a  type  field  (e.g.,  unused,  text,  data,  stack,  shared  memory) 

•  read-only  flag 

Entries  in  the  system  region  table  contain  the  following  fields: 

•  type  of  the  region  (e.g.,  unused,  private  (not  sharable),  shared  text,  shared  memory) 

•  various  status  flags  (e.g.,  loaded,  locked,  locked  with  process  waiting,  private) 

•  sise  of  region  in  pages 
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•  an  r-list,  which  is  a  pointer  to  a  list  of  pointers  to  PDTs  and  Disk  Block  Descriptors 
(see  below) 

•  number  of  page  tables  allocated  to  r-list 

•  if  region  is  on  the  free  Ust,  pointers  to  the  regions  before  and  after  on  free  list 

•  pointer  to  inode  where  blocks  are 

For  each  PDT,  a  Disk  Block  Descriptor  table  is  allocated  (contiguously).  For  each  PDT  entry  there 
is  a  corresponding  Disk  Block  Descriptor  table  entry  which  contains  information  describing  a  copy  of 
the  page  on  disk  if  one  exists. 
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PROCESS  TABLE 


PROCESS  DATA  STRUCTURES 

Figure  S.  Process  Data  Structures 
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2.4.1.4  Process  Creation  and  Execution 

The  only  method  of  process  creation  available  to  the  user  is  to  invoke  the  fork  system  call.  The 
process  that  makes  a  fork  call  is  referred  to  as  the  parent  process,  and  the  newly  created  process  is 
referred  to  as  the  child  process.  Every  process  has  only  one  parent,  but  can  have  several  children. 
Immediately  after  execution  of  the  fork  call,  the  only  differences  between  the  parent  process  and 
child  process  are  the  fact  that  the  child  process  ID  and  the  parent  process  ID’s  are  distinct,  the 
PPIDs  differ,  and  some  accounting  flags  are  re-initialized. 

A  successful  fork  system  call  causes  the  kernel  to  perform  the  following  sequence  of  operations: 

•  allocates  an  entry  in  the  process  table  for  the  child 

•  assigns  a  unique  process  ID  to  the  child 

•  copies  data  (e.g.  parent  process  real  and  effective  user  IDs,  parent  process  IDs)  Grom 
the  parent  process  table  entry  to  the  child’s  process  table  entry 

•  increments  the  Ole  and  inode  table  counters 

•  makes  a  logical  copy  of  the  parent’s  text,  data,  stack  and  user  area 

•  returns  the  child’s  process  ID  to  the  parent 

•  returns  0  to  child  process 

After  the  process  has  been  created  by  the  fork  call,  the  exec  system  call  can  be  run  to  overlay  the 
memory  space  of  the  newly  created  process  with  a  copy  of  an  executable  file.  The  kernel  checks  the 
execute  permissions  for  the  executable  file,  and  the  size  of  the  file  against  the  limits  of  the  invoking 
process.  Next  the  kernel  determines  the  layout  of  the  executable  Hie  and  overlays  the  text  and  data 
regions.  Upon  invoking  exec,  signals  set  to  be  caught  by  the  invoking  process  are  set  to  terminate 
the  transformed  process.  Finally,  the  process  is  placed  on  the  run  queue  and  awaits  execution.  The 
exec  system  call  will  fail  if  any  of  the  following  are  true: 

•  the  new  process  file  is  not  an  ordinary  file 

•  the  new  process  is  a  shared  text  file  that  is  currently  open  for  write  by  some  process 

•  not  enough  memory 

•  a  signal  was  caught  during  the  exec  system  call 

•  attempting  to  load  a  program  whose  size  exceeds  the  system  limit 

•  attempting  to  load  a  SGID  Hie  when  no  privilege  for  the  combination  of  security 
label  and  discretionary  group  exists  within  the  system 

2.4.1.5  Signaling 

Processes  may  send  other  processes  signals  via  the  kill  system  call,  or  the  kernel  may  send  processes 
signals  by  directly  writing  the  signal  into  the  p_sig  Held  of  the  process  table  entry.  The  following 
chart  identifies  the  signals  supported  on  System  V/MLS: 
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TYPE 

VALUE 

MEAMN6 

SIGHUP 

01 

hangup 

SIGINT 

02 

interrupt 

SIGQUIT 

03 

quit 

SIGILL 

04 

illegal  instruction 

SIGTRAP 

05 

trace  trap 

SIGIOT 

06 

currently  used  as  an  abort  signal 

SIGEMT 

07 

Alignment  Error 

SIGFPT 

08 

floating  point  exception 

SIGKILL 

09 

kill 

SIGBUS 

10 

bus  error 

SIGSEGV 

11 

segmentation  violation 

SIGSYS 

12 

bad  argument  to  system  call 

SIGPIPE 

13 

write  on  pipe  with  no  one  to  read 

SIGALRM 

14 

alarm  clock 

SIGTERM 

IS 

software  termination 

SIGUSRl 

16 

user  defined  signal  1 

SIGUSR2 

17 

user  defined  signal  2 

SIGCLD 

18 

death  of  child 

SIGPWR 

19 

power  failure 

20 

user  defined  signal  3 

21 

user  defined  signal  4 

SIGPOLL 

22 

pollable  event  occurred 

When  a  process  sends  a  signal  via  the  kill  system  call,  the  real  or  effective  UID  of  the  sending 
process  must  be  the  same  as  the  SAVED  or  effective  UID  of  the  receiving  process;  the  only 
exception  is  the  case  when  the  effective  UID  of  the  sending  process  is  superuser  (root).  The 
superuser  can  send  a  signal  to  any  process. 

A  signal  will  not  be  sent  if  one  or  more  of  the  following  are  true; 

-  the  signal  number  is  not  valid 

-  the  signal  is  a  SIGKILL  and  the  receiving  process  ID  is  1 

-  the  real  or  effective  UID  of  the  sending  process  is  not  superuser,  ot  its  real  or  effective 
UID  does  not  match  the  saved  or  effective  UID  of  the  receiving  process 

-  no  process  can  be  found  corresponding  to  the  specified  process  ID 

-  the  system’s  mandatory  access  control  policy  is  violated  and  the  effective  UID  of  the 
sending  process  is  not  superuser 

The  kernel  sends  a  signal  to  a  process  by  setting  a  bit  in  the  signal  field  (p_sig)  of  the  process  table 
entry  which  corresponds  to  the  type  of  signal  sent.  If  the  process  is  sleeping  at  an  interruptible 
priority  wd  receives  a  signal,  the  kernel  awakens  it. 

Signals  are  not  queued,  so  if  a  process  receives  the  same  signal  more  than  once  before  processing  the 
previous  occurrence,  then  those  additional  signals  are  ignored.  If  a  process  receives  different  signals 
at  the  same  time,  then  the  one  with  the  lower  signal  number  is  processed  Hrst. 


Revision  10.4 


-  35- 

overview.mm 


(Revised  5/24/91) 


Final  Evaluation  Report  ATftT  System  V/MLS 
System  Overview 


The  TCB  checks  for  signals  before  a  process  returns  from  kernel  mode  to  user  mode  and  when  it 
enters  or  leaves  the  sleep  state.  The  process  that  receives  the  signals  may  react  to  them  in  one  of 
the  following  manners: 

-  by  default  the  process  calls  txit  and  terminates 

-  the  process  may  ignore  the  signal  (except  for  SIGKILL) 

-  the  process  may  execute  a  particular  user  function 

A  process  can  only  respond  to  a  signal  while  in  user  mode;  therefore  signals  do  not  have  an 
immediate  effect  on  processes  running  in  kernel  mode.  If  a  process  is  running  in  user  mode  and 
receives  a  signal,  the  kernel  will  respond  to  the  interrupt  and  then  return  to  the  user  process. 

2.4.1.6  Process  Termination 

The  txit  system  call  terminates  the  executing  process.  The  kernel  determines  if  the  calling  process  is 
a  process  group  leader.  If  the  process  is  a  process  group  leader,  all  members  of  the  group  are  sent  a 
SIGHUP  signal,  and  their  process  group  number  is  changed  to  sero. 

Exit  then  causes  the  kernel  to  do  the  following: 

-  disable  the  process’s  ability  to  handle  signals 

-  close  all  open  files  associated  with  the  process 

•  free  memory  associated  with  the  process  by  deallocating  the  appropriate  regions 

-  change  the  process  state  to  "sombie'.  A  sombie  process  is  one  that  still  has  an  entry  in 
the  process  table  but  doesn’t  have  a  user  area  associated  with  it.  Init  removes  a  sombie 
process  from  the  process  table  when  its  parent  exits. 

•  save  the  accumulated  kernel  and  user  mode  execution  times  of  the  process  in  the 
process  table 

-  change  the  parent  of  any  remaining  child  processes  to  process  1  (the  init  process) 

-  sends  a  'death  of  child'  signal  to  the  parent  process  so  process  1  can  remove  it  frx>m 
the  process  ^able. 

-  resume  scheduler  which  chooses  next  process  to  run  and  performs  a  context  switch 

2.4.2  Objects 

System  V /MLS  supports  the  following  objects: 
regular  files 
special  files 
directories 
named  pipes 
unnamed  pipes 
shared  memory  segments 
message  queues 
semaphores 
processes 

This  report  abo  discusses  630  MTG  buffers  which  are  system  objects  (as  are  the  process  table,  u- 
area,  etc).  630  MTG  buffers  are  emphasised  due  to  their  unique  nature. 
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Of  thea«  objects,  all  are  represented  as  part  of  the  file  system  except  for  message  queues, 
semaphores,  shared  memory  segments,  processes,  and  the  630  MTG  buffers.  All  of  these  objects  are 
named  objects  subject  to  the  system’s  discretionary  access  policy  except  for  unnamed  pipes  and  630 
MTG  buffers.  The  file  system  object  access  control  information  can  be  found  in  the  inode  for  that 
object.  The  non-file  system  objects  each  have  storage  data  structures  which  contain  their  access 
control  information. 

There  are  three  basic  access  types  allowed  in  System  V/MLS: 

READ  -  Any  operation  that  results  in  a  flow  of  information  from  an  object  to  a  subject. 

WRITE  -  Any  operation  that  results  in  a  flow  of  information  from  a  subject  to  an  object  or 

that  causes  a  change  of  state  within  an  object. 

EXECUTE  -  Execute  access  on  a  file  allows  the  loading  and  running  of  the  contents  of  that  file 
(object).  Execute  access  on  a  directory  allows  a  subject  to  search  the  directory  for  a 
file  name. 

The  following  section  provides  a  description  of  each  of  the  object  types.  These  descriptions  include 
usage,  design,  and  implementation.  There  is  some  discussion  of  access  policies  and  features, 
although  details  can  be  found  in  the  discretionary  and  mandatory  access  sections  of  this  report  (see 
page  42,  'Discretionary  Access  Control’  and  page  44,  'Mandatory  Access  Control'). 

2.4.2.1  Regular  Filee 

Regular  files  are  the  primary  information  containers  for  the  system.  Any  data  can  be  placed  into  a 
file.  Allowable  access  types  for  regular  files  are  read,  write,  and  execute. 

2.4.2.2  Directaries 

A  directory  is  simply  a  file  containing  the  names  of  those  files  which  reside  in  it  and  their  inode 
numbers.  It  is  possible  for  a  directory  to  contain  an  upgraded  file  or  directory.  It  should  be  noted 
that  files  must  be  created  in  a  directory  at  the  level  of  the  directory.  This  is  a  consequence  of  the 
System  V/MLS  'write  equal  only'  policy.  Therefore,  the  only  way  for  a  directory  to  contain  an 
upgraded  ffle,  is  for  the  file’s  classification  to  be  upgraded  using  the  chpriv  command.  The  upgraded 
file  name  or  directory  name  must  be  at  the  same  label  as  the  containing  directory;  thus  making  it 
visible  at  the  label  of  the  containing  directory.  The  attributes,  other  than  file  name  and  inode 
number,  are  at  the  upgraded  label  and  are  therefore  only  visible  at  that  upgraded,  or  higher  label. 
Some  directories  can  ^  marked  as  SECURED,  and  are  treated  differently  by  the  TCB  (see  page  55, 
'SECURED  Directories'). 

Under  normal  circumstances  the  TCB  ensures  that  a  directory’s  label  dominates  the  label  of  its 
parent  directory.  Thus,  as  one  traverses  a  path  from  the  root  to  a  file  system  object,  the  labels  are 
monotonicaUy  non-decreasing.  It  is  possible,  however,  for  a  trusted  user  to  downgrade  a  file  or 
directory  which  could  leave  that  part  of  the  file  system  non-monotonically  non-decreasing.  This 
happens  when  a  file  has  been  reclassified  (via  chpriv)  such  that  the  containing  directory’s  label  is 
greater  than  the  file’s  new  label  (  see  page  53,  'Reclassifying  Information').  Although  the  file  has 
been  reclassified,  it  is  still  protected  at  the  (higher)  label  of  the  containing  directory.  This  is  because 
a  process  must  be  operating  at  the  label  of  the  containing  directory  in  order  to  traverse  the  path  to 
the  reclassified  file  and  read  it.  However  this  process  would  not  be  able  to  write  the  file.  To  restore 
the  norm:d  file  system  hierarchy,  the  file  would  have  to  be  moved  via  the  mvpriv  trusted  process. 
Mvpriv  ensures  that  the  invoker  has  discretionary  search  and  write  access  to  the  containing  directory 
and  the  target  directory  and  that  the  invoker  is  operating  at  the  label  of  the  containing  directory. 


Revision  10.4 


-  37- 

overview.mm 


(Revised  5/24/91) 


Final  Evaluation  Report  ATJtT  System  V/MLS 
System  Overview 


Finally  mvpriv  ensures  that  the  target  directory’s  label  is  equal  to  the  file’s  new  label.  Allowable 
access  types  for  directories  are  read,  write,  and  execute. 

2.4.2.3  Special  Files 

Special  files  are  Hie  system  objects  which  are  used  to  represent  devices  and  can  be  manipulated  by 
user  processes.  For  special  Hies  that  represent  single-level  devices,  the  label  of  the  special  file  as 
recorded  by  the  file  system  is  used.  Storage  medium  devices  are  multi-level  devices;  the  630  MTG 
terminal  is  a  multi-level  device  represented  by  multiple  single-level  pseudodevices.  Access  to  multi¬ 
level  device  Hies  is  restricted  to  trusted  processes  that  enfcH-ce  the  labeling  requirements. 

User  terminak,  except  for  the  630  MTG,  are  single  level  devices  that  can  operate  at  only  one  label 
at  a  time.  This  range  has  a  maximum  security  label  and  a  minimum  security  label  defined  in  a 
device  clearances  database  (the  /m/s/c/eardev  file).  The  maximum  security  label  must  dominate  ’he 
minimum  security  label.  No  device  is  ever  allowed  to  operate  outside  the  range  of  security  labels 
specified  by  its  maximum  and  minimum  security  labels.  Allowable  access  types  on  special  files  are 
read  and  write;  execute  access  does  not  have  any  effect  on  special  files. 

2.4.2.4  Named  Pipes 

Named  pipes  are  file  system  objects  used  as  communication  buffers  between  two  processes.  Named 
pipes  provide  an  interprocess  communication  facility  that  manages  data  in  a  Hrst-in,  first-out 
manner.  A  process  granted  read  access  to  a  named  pipe  may  extract  the  oldest  information  in  the 
named  pipe.  Extracting  the  information  deletes  it  from  the  named  pipe.  A  process  grai».ed  write 
access  to  a  named  pipe  can  append  information  to  the  named  pipe.  Allowable  access  types  for 
named  pipes  are  read  and  write;  execute  access  does  not  have  any  effect  on  named  pipes. 

2.4.2.5  Unnamed  Pipes 

Unnamed  pipes  provide  an  interprocess  communication  facility  like  named  pipes.  Unnamed  pipes  do 
not  have  names  in  the  file  system;  however,  they  are  represented  in  the  file  system  with  inodes. 
Unnamed  pipes  can  be  used  as  communication  buffers  between  a  child  process  and  its  parent  process 
and  between  sibling  processes.  Since  this  communication  can  only  occur  if  the  pipe’s  file  descriptor 
is  passed  on  to  the  child  from  the  parent  as  part  of  the  process  context  duplicated  when  the  child  is 
forked,  no  other  access  control  is  enforced  except  in  the  case  of  executing  a  newpriv  command.  For 
an  explmiation  of  the  newpriv  command,  see  page  51,  'Changing  Subject  Sensitivity  Label 
Interactively'.  Allowable  access  types  for  unnamed  pipes  are  read  and  write;  execute  access  does 
not  have  any  effect  on  unnamed  pipes. 

2.4.2.6  System  Y  UPC  Objects 

There  are  three  IPC  mechanisms  in  System  V/MLS  known  as  System  V  IPC:  messages,  semaphores 
and  shared  memory  segments.  Although  each  is  intended  for  a  specific  use,  they  ail  share  common 
implementation  properties.  These  properties  are  as  follows: 

—  A  kernel  resident  table  exists,  one  per  mechanism,  which  contains  entries  describing 
all  instances  of  the  mechanism.  For  messages  there  is  a  system  mess^e  table  whose 
entries  describe  all  current  IPC  messages,  for  semaphores  there  is  a  system 
semaphore  table  whose  entries  describe  all  instances  of  semaphores,  and  for  shared 
memory  segments  there  is  a  system  shared  memory  table  whose  entries  describe  all 
instances  of  shared  memory  segments. 
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—  Each  entry  in  one  of  the  three  system  tables  contains  the  following  information: 

-  numeric  key  (user-choeen  name) 

-  creator  UID/GID  (IDs  from  the  creating  process) 

-  owner  UID/GID  (IDs  originally  the  same  as  those  of  the  creator,  but 
may  be  changed  by  the  creator  or  owner) 

•  set  of  permission  bits  for  user,  group,  others  (see  page  42,  'Discretionary 
Access  Control') 

-  status  information  (e.g.,  last  process  to  update  the  entry,  time  of  last 
access,  number  of  processes  attached) 

—  Each  type  of  mechanism  is  associated  with  a  corresponding  'get'  system  call  to 
create  a  new  entry  or  retrieve  an  existing  one  (i.e.,  msget,  semget,  skmget).  A 
process  supplies  a  user-chosen  key  to  the  call.  The  kernel  searches  the  appropriate 
system  table  to  see  if  an  entry  exists  for  the  given  key.  The  table  is  searched  on  the 
key  field  which  is  contained  in  each  entry  of  the  table.  If  no  entry  exists  the  kernel 
allocates  a  new  structure,  initialises  it,  and  returns  an  identifier  (ID)  to  the  user.  If 
an  entry  exists  for  the  given  key,  the  kernel  checks  permissions  for  the  entry  and  if 
access  is  allowed  for  the  requesting  process,  the  identifier  for  the  entry  is  returned.  A 
creating  process  can  be  assured  of  obtaining  an  unused  entry  by  specifying  the  key 
'IPO_PRIVATE'  to  the  caU. 

—  For  each  mechanism,  the  identifier  returned  from  a  'get'  system  call  is  based  on  the 
index  into  the  table  for  the  data  structure  (index  =  identifier  modulo  (number  of 
entries  in  table)).  When  a  process  removes  an  entry,  the  kernel  increments  the 
identifier  associated  with  it  by  the  number  of  entries  in  the  table.  Processes  that 
attempt  to  access  the  entry  by  its  old  identifier  fail  on  their  access. 

—  Each  mechanism  is  associated  with  a  corresponding  set  of  'operation'  system  calls: 
mtgsnd,  msgrcv  for  messages,  semop  for  semaphores,  shmat,  shmdt  for  shared  memory 
segments.  For  all  of  these  calls,  a  process  must  specify  an  appropriate  identifier  to 
the  call  (i.e.,  the  ID  returned  from  the  'get'  system  call).  The  kernel  then  checks 
that  the  invoking  process  has  appropriate  access  to  the  corresponding  entry,  (see 
page  43,  'DAG  on  System  V  IPC  Objects').  Note  that  this  prevents  a  process  from 
successfully  gaining  access  to  an  entry  by  guessing  at  the  entry  ID. 

—  Each  mechanism  is  associated  with  a  corresponding  'control'  system  call:  imgctl, 
semetl,  skmeti.  These  calls  allow  a  process  to  query  status  information  about  an 
entry,  set  status  information,  or  nmove  an  entry  from  the  system.  A  process  must 
have  read  access  to  the  entry  to  query  status  information.  In  order  to  set  status 
infmmation  or  remove  an  entry,  however,  the  process  UID  must  match  the  creator 
UID  or  the  owner  UID.  Creatm-  UID  and  GID  fields  can  never  be  changed,  so  the 
creating  user  always  retains  'control'  access  to  the  entry.  Since  the  owner  can 
change  permission  bits,  rw  access  to  the  entry  can  be  taken  away  from  the  creator, 
however,  because  the  creatm'  will  still  retain  'control'  access,  he  can  always  give 
himself  back  rw  access. 

The  following  three  sections  describe  each  of  the  IPC  objects. 
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2.4.2.6.1  Semaphores 

Semaphores  are  objects  that  are  used  to  implement  a  process  synchronisation  mechanism.  System  V 
semaphores  are  a  generalisation  of  the  P  and  V  operations  described  by  Dijkstra  ^  in  that  several 
operations  can  be  done  simultaneously,  and  increment  and  decrement  operations  can  be  by  values 
greater  than  one.  System  V  semaphores  can  therefore  take  on  any  numeric  value  and  be  used  to 
control  access  to  a  resource  (i.e.,  locking/unlocking)  or  to  share  a  small  value  between  processes. 
Allowable  access  types  for  semaphores  are  read  and  write;  execute  access  does  not  have  any  effect  on 
semaphores. 

2.4.2.6.2  Message  Queues 

Message  queues  are  containers  for  messages  which  are  primarily  used  to  hold  requests  to  server 
processes. 

A  process  granted  read  access  to  a  message  queue  may  extract  the  oldest  message  from  that  message 
queue.  Extracting  the  message  deletes  it.  A  process  granted  write  access  to  a  message  queue  may 
append  messages  to  the  message  queue.  Allowable  access  types  for  message  queues  are  read  and 
write;  execute  access  does  not  have  any  effect  on  message  queues. 

2.4.2.6.3  Shared  Memory  Segments 

Shared  memory  segments  are  used  to  allow  multiple  processes  to  access  the  same  information 
without  the  overhead  of  multiple  copies.  A  description  of  how  shared  memory  is  implemented  can 
be  found  on  page  25,  'Memory  Allocation'.  Shared  memory  provides  the  fastest  means  of 
exchanging  data  between  two  processes.  Allowable  access  types  for  shared  memory  segments  are 
read  and  write;  execute  access  does  not  have  any  effect  on  shared  memcny  segments. 

2.4.2.7  Processes 

Although  processes  are  the  subjects  in  the  System  V/MLS  system,  when  they  are  viewed  as  the 
recipient  of  a  signal  they  must  be  treated  as  objects.  Processes  are  represented  by  entries  in  the 
process  table. 

When  a  program  overlays  a  process  via  exec,  the  saved  UID  is  set  equal  to  the  effective  UID;  the 
real  UID  remains  as  it  was.  This  way,  a  process  can  move  back  and  forth  between  the  saved  UID 
and  real  UID.  However,  if  the  effective  UID  of  a  process  k  0  (i.e.,  superuser),  invoking  the  eetuid 
system  call  will  set  all  three  UIDs  to  the  new  value.  Therefore  a  process  cannot  reclaim  root 
permissions  once  it  has  given  them  up. 

In  order  for  a  process  to  be  allowed  to  send  a  signal  to  another  process,  the  real  or  effective  UID  of 
the  sending  process  must  match  the  saved  or  effective  UID  of  the  receiving  process,  unless  the 
effective  UID  of  the  sending  process  is  superuser.  Also,  the  classification  level  of  the  sending  process 
must  match  the  classification  level  of  the  receiving  process,  unless  the  effective  UID  of  the  sending 
process  is  superuser.  For  more  details  on  signals,  see  page  34,  'Signaling'. 


5.  Dgkstrs,  E.W.,  'Cooperating  Seqnential  Processes', 
in  ’Progremmine  Lengutgee', 

ed.  F.  Gennys,  Academic  Press,  New  York,  NY,  1968, 


Revision  10.4 


-40- 

overview.mm 


(Revised  5/24/91) 


Final  Bralnatlon  Report  ATRT  Systen  V/NL8 

Systen  Overview 


2.4.2.8  630  MTG  Window  Buffers 

The  window  buffers  on  the  630  MTG  are  associated  with  the  process  that  is  currently  running  on 
the  terminal.  These  storage  objects  are  discussed  further  in  the  section  or  page  71,  'The  630  MTG 
Terminal  Implementation*. 

2.4.3  TCB  Protection  Mechanisms 

The  System  V/MLS  TCB  protects  itself  and  users*  data  through  the  use  of  hardware  and  software 
protection  mechanisms.  The  following  sections  discuss  these  protection  mechanisms. 

2.4.3.1  Hardware  Protection  Mechaidsnis 

System  V/MLS  utilises  the  system  hardware  architecture  to  provide  for  a  trusted  computing 
environment.  Hardware  elements  that  are  esaential  in  providing  this  environment  include  privileged 
execution  modes  and  the  virtual  system  environment  provided  to  users.  These  two  concepts,  along 
with  the  special  controls  afforded  to  the  630  MTG  terminal  provide  a  protected  user  environment. 

2.4.3.1.1  Hardware  Protection 

The  System  V/MLS  hardware  is  based  upon  the  WE  32100  Central  Processing  Unit,  in  conjunction 
with  the  WE  32101  Memory  Management  Unit.  This  com'jination  provides  an  environment  for 
users  which  enforces  restrictions  on  the  ability  of  users  to  access  data.  The  data  access  restrictions 
are  provided  by  three  mechanisms:  access  determined  by  processor  execution  mode,  controlled  access 
within  a  given  execution  mode,  and  kernel  privileged  instructions. 

The  first  control  mechanism  involves  the  association  of  access  permissions  with  physical  memory 
segments.  For  every  physical  segment,  four  access  fields  are  specified,  one  fcxr  kernel,  executive, 
supervisor,  and  user  execution  modes.  These  access  fields  are  checked  when  access  is  requested  to  a 
segment.  If  the  processor  is  in  kernel  mode  when  it  requests  access,  the  access  decision  is  based 
upon  the  kernel  permission  Held.  When  executing  in  user  mode,  the  user  permission  field  is  used. 
The  specifiable  permissions  to  a  physical  page  are;  read/write/execute  (RWE),  read/execute  (RE), 
execute  only  (EO),  and  no  access  (NA). 

The  second  control  mechanism  involves  the  protection  of  data  between  users  at  the  same  execution 
raode.  The  system  provides  a  virtuaLto-physical  translation  mechanism,  which  isolates  the  data 
accessible  to  users.  The  translation  tables  needed  for  this  mechanism  are  controlled  by  the  TOB, 
and  protected  fi^m  unauthorised  modification.  This  protection  involves  placing  the  tables  into 
memory  that  is  only  accessible  while  the  processor  is  in  kernel  mode,  and  restricting  the  ability  to 
enter  kernel  mode.  This  ensures  that  only  the  TCB  wiU  be  capable  of  modifying  the  tables  which 
define  the  virtual  system  environment.  See  page  25,  'Memory  Allocation',  for  a  detailed  discussion 
of  the  translation  mechanism. 

The  third  control  mechanism  consists  of  the  set  of  kernel  privileged  instructions.  These  kernel 
privileged  instructions,  which  may  manipulate  machine  resources  (e.g.,  physical  memory,  hardware 
interrupts),  are  restricted  to  processes  operating  in  kernel  mode.  Since  only  the  TCB  operates  in 
kernel  mode,  non-privikged  users  are  prevented  from  using  these  instructions.  For  more  information 
on  kernel  privileged  instructions,  see  page  5,  'Instruction  Set'. 

2.4.3.2  Software  Protection  Mechaidanie 

As  discussed  previously  (see  page  24,  'TCB  Boundary'),  the  software  portion  of  the  TCB  is 
composed  of  those  routines  running  in  kernel  space  and  trusted  processes.  The  TCB  is  ciqiable  of 
protecting  the  TCB  routines  and  data  files  from  unauthexised  modification  through  the  routine 
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enforcement  of  the  mandatory  and  discretionary  access  control  policy. 

2.4.3.3  Discretltmary  Access  Control 

Discretionary  Access  Control  (DAC)  allows  owners  of  objects  to  grant  or  deny  access  to  the  named 
objects  which  they  own  based  upon  user-defined  information  sharing  requirements.  System  V/MLS 
named  objects  are  identified  on  page  36,  'Objects'.  DAC  in  System  V/MLS  is  provided  through 
protection  bits.  Protection  bits  are  associated  with  all  System  V/MLS  named  objects  except 
processes.  Access  mediation  procedures  described  below  refer  to  discretionary  access  control  only. 
Of  course  mandatory  access  control  decisions  always  override  discretionary  access  control  decisions. 

2.4.3.3.1  DAC  on  Filesystem  Objects 

The  protection  bits  on  filesystem  objects  are  used  to  set  access  for  an  owner,  a  group,  or  all  others. 
The  creator  of  an  object  is  the  owner  and  at  object  creation,  each  object  is  marked  with  the  owner’s 
UID  and  GID.  After  object  creation,  however,  the  creator  may  transfer  ownership  to  another  user  or 
group  by  using  the  chown,  chgrp  or  chpriv  commands,  or  the  chown  system  call.  The  previous 
owner  then  loses  all  ownership  access  rights.  A  file’s  security  label  cannot  be  changed  if  the  file  is 
being  held  open  by  another  process  and  the  user’s  RUID  is  not  root. 

Once  a  subject  has  been  granted  access  to  an  object,  the  subject  retains  the  access  until  e  subject 
destroys  or  releases  the  object.  This  is  true  if  the  object’s  owner  changes  the  permissions  such  that 
the  subject  should  no  longer  be  capable  of  accessing  the  object,  or  even  if  the  owner  attempts  to 
delete  the  object,  any  subject  which  has  the  object  open  will  retain  access.  The  only  exception  to 
this  occurs  with  the  character  special  file  /dev/tty  (i.e.  a  user  terminal),  /dev/tty  has  access  checks 
performed  with  each  read  or  write  call;  thus,  an  access  permission  change  to  the  actual  terminal 
associated  with  /dev/tty  will  be  reflected  with  the  next  access  attempt. 

Each  object  is  also  associated  with  a  speciHc  'privilege',  which  is  System  V/MLS  terminology  for  a 
tuple  consisting  of  an  instantiation  of  a  discretionary  access  control  group  at  a  given  mandatory 
access  control  label.  The  'discretionary  group'  associated  with  the  object  corresponds  to  the 
traditional  UNIX  group  mechanism.  All  members  of  the  discretionary  group  have  discretionary 
access  permission  to  the  object  based  upon  the  setting  of  the  group  field  of  the  protection  bits.  Any 
named  object  inherits  its  privilege,  and  thus  its  discretionary  group,  from  the  process  which  created 
it;  however,  the  discretionary  group  of  a  named  object  may  be  changed  via  the  chgrp  or  chpriv 
commands  (these  commands  must  be  executed  by  the  owner  of  the  object).  There  is  no  limit  to  the 
number  of  groups  to  which  a  user  may  belong;  however,  a  user  may  only  operate  with  one  group’s 
identifier  in  effect.  Thus,  a  user  may  not  have  discretionary  access  to  a  file  in  group  A  while  the 
user  is  operating  as  a  user  in  group  B.  To  obtain  access  to  the  group  A  file,  the  user  may  change 
the  operating  discretionary  group  of  his  or  her  process,  and  thus  obtain  discretionary  access  rights  to 
the  object,  by  using  the  neuigrp  or  ncwpriv  commands.  In  System  V/MLS  a  group  can  be  created 
by  any  user;  however,  groups  with  special  access  rights  are  created  and  owned  by  the  system 
administrator.  For  a  complete  description  of  these  special  groups  see  page  51,  'Special  User 
Authorisations  on  System  V/MLS'. 

Access  granted  to  'other'  permits  all  other  users  of  the  system  discretionary  access  to  the  object. 

Each  file  is  represented  in  the  system  by  an  inode,  which  contains  the  owner  and  group  ID  of  the 
file.  The  owner’s  UID  and  the  group’s  GID  are  recorded  in  the  inode  at  file  creation.  Also  in  the 
inode  are  eleven  security  relevant  bits  associated  with  the  file;  nine  for  the  three  sets  of  access 
control,  and  one  each  for  the  SUID  and  SGID  bits.  For  a  description  of  SUID  and  SGID  see  page 
44,  'Setuid/Setgid  Mechanisms'. 


Revision  10.4 


-42- 

overview.mm 


(Revised  5/24/91) 


Final  Evaluation  Report  ATJ^T  System  V/MLS 

System  Oveinrlew 


Discretionary  access  to  a  file-system  object  is  checked  in  the  following  manner: 

Before  making  any  other  check,  the  kernel  ascertains  whether  the  effective  UID  of  the  process 
requesting  the  access  is  sero  (the  superuser).  If  so,  then  access  is  granted  immediately. 

1.  The  effective  user  ID  (EUID)  of  the  process  is  checked  against  the  owner  ID  of  the  file.  If  the 
EUID  matches  the  owner  ID  of  the  flie,  access  permission  is  checked  for  the  owner,  ff  the 
requested  permission  bit  for  the  owner  has  been  set,  access  is  granted.  Otherwise  access  is 
denied.  If  the  EUID  did  not  match,  the  check  continues. 

2.  If  access  has  not  been  determined,  the  effective  discretionary  group  ID  of  the  process  is 
checked  against  the  discretionary  group  ID  of  the  object.  If  the  Effective  Group  ID  (EGID) 
matches  the  dbcretionary  group  ID  of  the  object,  access  permission  is  checked  for  the  group. 
If  the  requested  permission  bit  for  the  group  has  been  set,  access  is  granted.  Otherwise  access 
is  denied.  If  the  EGID  did  not  match,  the  check  continues. 

3.  If  access  has  not  already  been  determined,  the  'other'  bits  are  checked.  If  the  requested 
permission  for  'other'  has  been  set,  access  is  granted.  Otherwise  access  is  denied. 

A  user  may  alter  the  discretionary  access  control  attributes  of  a  Hie  by  using  the  chmod  command  or 
system  call.  This  commauid  allows  the  owner  of  a  file  to  change  the  protection  bits  on  that  file.  The 
umaak  command  specifies  the  default  protection  bit  settings  when  a  file  is  created.  Any  bits  set  to 
'1'  in  the  umask  will  be  cleared  in  that  file’s  protection  bits  upon  file  creation  (i.e.  the  protection 
bits  on  the  newly  created  file  will  be  the  negation  of  the  umask  setting).  The  default  umask  for  the 

system  is  --xrwxrwx  (177).  This  results  in  initial  access  of  rw -  (600),  meaning  that  only  the 

owner  has  access  to  the  object  and  all  other  users  have  no  access. 

2.4.3.3.2  DAC  on  System  V  IPC  Objects 

Protection  bits  for  user,  group,  and  other  are  also  associated  with  an  IPC  object,  whether  it  be  a 
message,  semaphore,  or  shared  memory  segment.  These  permission  bits  are  stored  in  the  IPC 
object’s  associated  system  table  entry  as  described  on  page  38,  'System  V  IPC  Objects'.  The  SUID 
and  SGID  bits  are  not  meaningful  for  IPC  objects,  as  IPC  objects  are  not  executable.  An  IPC 
object  has  both  a  creator  and  an  owner  associated  with  it,  and  at  object  creation,  the  creator  and 
the  owner  of  the  IPC  object  are  the  same.  The  creator  (or  the  owner)  may  change  the  owner  UID, 
owner  GID,  and  the  permission  bits  associated  with  the  object  through  the  IPC  'control'  system 
call  (i.e.,  msgctl,  aemctl,  or  ahmctl).  The  creator  UID  and  GID  can  never  be  changed  and  therefore 
the  creator  always  retains  'control'  access  to  the  object. 

Since  each  IPC  object  has  associated  with  it  both  a  creator  UID  and  GID,  and  an  owner  UID  and 
GID,  there  is  an  additional  check  made  when  determining  discretionary  access.  Access  to  an  IPC 
object  is  checked  in  the  following  manner: 

If  the  effective  UID,  EUID,  of  the  process  is  root,  access  is  granted. 

1.  The  EUID  of  the  process  is  checked  against  the  creator  UID  and  the  owner  UID  of  the  object. 
If  either  matches,  and  the  requested  permission  bit  for  the  creator  or  owner  has  been  set, 
access  is  granted.  Otherwise  access  is  denied.  If  the  EUID  did  not  match,  the  checx 
continues. 

2.  The  EGID  of  the  process  is  checked  against  the  creator  GID  and  the  owner  GID  of  the  object. 
If  either  matches,  and  the  requested  permission  for  the  group  has  been  set,  access  is  granted. 
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Otherwise  access  is  denied.  If  the  EGID  did  not  match,  the  check  continues. 

3.  If  access  has  not  yet  been  determined,  the  'other'  bits  are  checked.  If  the  requested 
permission  for  other  has  been  set,  access  is  granted.  Otherwise  access  is  denied. 

As  mentioned  previously,  the  creator  or  owner  of  an  IPC  object  can  change  the  owner  GID.  The 
owner  GID,  however,  can  only  be  changed  to  a  privilege  at  the  same  sensitivity  level  as  the  original 
owner  GID.  If  a  process  attempts  to  change  the  owner  GID  to  that  of  a  privilege  at  a  different 
level,  the  resulting  GID  will  be  the  discretionary  group  of  the  requested  GID  and  the  current  level  of 
the  IPC  object.  A  check  is  made  to  ensure  that  such  a  resulting  privilege  exists  on  the  system. 
MAC  checks  for  IPG  objects  are  only  performed  agednst  the  owner  GID. 

2.4.3.3.3  Setoid/Setgid  Mechanisms 

The  high  order  two  protection  bits  of  a  file  are  the  set-user-ID  (SUID)  and  the  set-group-ID  (SGID) 
bits.  These  bits  have  no  meaning  unless  the  file  is  an  executable  program.  When  the  SUID  bit  has 
been  turned  on  (via  the  chmod  command  or  system  call)  and  the  program  is  later  executed,  the 
effective  UID  is  copied  to  the  saved  UID  as  in  a  normal  exec,  and  the  UID  of  the  executed  program 
becomes  the  effective  UID  of  the  resulting  process.  When  the  SGID  bit  has  been  turned  on  and  the 
program  is  later  executed,  the  resulting  process  is  given  a  GID  which  reflects  the  sensitivity  level  of 
the  invoking  process  and  the  discretionary  group  of  the  program,  provided  that  the  resulting 
privilege  is  defined  on  the  system.  The  process  now  has  all  the  discretionary  access  rights  of  the 
owner  of  the  program  (and/or  the  owner’s  group)  but  the  actions  of  the  process  are  controlled  by 
the  program.  The  process  can  change  its  effective  UID  to  either  the  "real'  UID  (the  UID  of  the 
user  who  invoked  the  process)  or  the  "saved'  UID  (the  UID  of  the  owner  of  the  setuid  program), 
resulting  in  the  process  having  the  sum  of  both  users’  discretionary  access  rights.  If  the  effective 
UID  is  0  (superuser),  changing  the  effective  UID  is  irreversible  since  the  EUID,  RUID,  and  saved 
UID  all  get  changed  to  the  UID  of  the  program. 

System  V/MLS  provides  protection  against  some  misuses  of  the  SUID  mechanism.  If  the  ownership 
of  a  fde  is  changed,  the  SUID/SGID  bits  are  cleared.  Also,  if  the  file’s  group  is  changed,  the 
SUID/SGID  bits  are  cleared.  If  a  file  is  modified  by  any  user  other  than  the  owner,  the 
SUID/SGID  bits  are  cleared.  Upon  execution  of  a  SGID  file,  the  exec  system  call  sets  the  effective 
GID  to  a  GID  that  preserves  the  security  label  associated  with  the  subject.  SUID  attacks  ag^st 
superuser  are  more  difficult  because  no  process  can  execute  with  superuser  privilege  unless  the 
executed  code  has  been  labeled  at  SYSTEM  level.  Untrusted  users  are  never  cleared  to  SYSTEM 
level  and  hence  cannot  create  a  file  executable  by  superuser.  The  System  V/MLS  /bin/sh  does  not 
allow  SUID/SGID  privileges  to  be  inherited  by  processes  spawned  from  SUID/SGID  processes  via 
shell  commands. 

It  is  still  possible,  however,  for  the  DAC  policy  to  be  violated  if  users  fail  to  write  well-behaved 
SUID/SGID  programs.  System  V/MLS  addresses  this  problem  by  providing  a  configurable  option  to 
deny  the  setting  of  the  SUID  and  SGID  bits  on  files  by  anyone  other  than  superuser.  This  allows 
the  administrator  to  inspect  any  candidate  SUID/SGID  programs  proposed  by  users  or  hidden  in 
applications  before  they  are  installed. 

2.4.3.4  Mandatory  Access  Control 

Mandatory  security  is  enforced  by  System  V/MLS  over  all  subjects  and  objects.  Subjects  and 
objects  are  labeled  as  described  on  page  45,  'Labels  on  System  V/MLS',  and  these  labels  are  used 
to  enforce  the  mandatory  security  policy.  Labels  are  assigned  and  maintained  by  the  TCB,  and  may 
only  be  modified  through  trusted  software. 


Revision  10.4 


-44- 

overview.mm 


(Revised  5/24/91) 


Final  Evaluation  Report  ATIcT  System  V/MLS 

System  Overview 


The  mandatory  security  policy  enforced  by  System  V/MLS  relies  upon  two  basic  relationships 
between  labels.  These  relationships  are: 

Dominance:  When  label  X  dominates  label  Y,  the  hierarchical  portion  of  label  X  is 

greater  than  or  equal  to  the  hierarchical  portion  of  label  Y,  and  label  X 
contains  at  least  all  of  the  non-hierarchical  categories  that  are  contained  in 
label  Y.  This  check  is  performed  within  the  kernel  by  the  routine 
rrdajiom. 

Equivalence:  When  label  X  is  equivalent  to  label  Y,  the  hierarchical  portion  of  label  X  is 

identical  to  the  hierarchical  portion  of  label  Y,  and  the  set  of  non* 
hierarchical  categories  contained  in  label  X  is  identical  to  the  set  of  non- 
hierarchical  categories  contained  in  label  Y.  This  check  is  performed 
within  the  kernel  by  the  routine  rrd3_eqv: 

System  V/MLS  supports  three  basic  access  modes  to  objects:  read,  write,  and  execute.  The 
mandatory  security  policy  supported  by  System  V/MLS  controls  the  basic  access  modes  such  that 
data  is  not  compromised  to  unauthorised  users  in  accordance  with  the  following  controls: 

To  grant  a  subject  read  access,  the  label  of  the  subject  must  dominate  the  label  of  the  object. 

To  grant  a  subject  write  access,  the  label  of  the  subject  must  be  identical  to  the  label  of  the  object. 

To  grant  a  subject  execute  access,  the  label  of  the  subject  must  dominate  the  label  of  the  Hie 
object. 

2.4.3.4.1  Labels  on  System  V/MLS 

System  V/MLS  uses  the  UNIX  group  ID  (GID)  to  implement  its  labeling  scheme.  GlDs  are 
associated  with  each  subject  through  the  process  table  and  with  each  object  as  part  of  the  inode  or 
IPG  data  structure.  When  an  object  is  created,  its  label  is  that  of  the  creating  process.  A  child 
process  inherits  the  label  of  its  parent  process.  At  login,  the  process  receives  a  default  label 
according  to  what  is  specified  in  the  /mls/paasrud  file  For  a  complete  description  of  how  this  works, 
see  page  59,  'User  Identification  and  Authentication'. 

Every  label  has  two  parts;  a  hierarchical  level  and  a  set  of  non-hierarchical  categories.  The 
hierarchical  level  is  represented  by  a  number  from  0  to  255.  All  levels  are  defined  by  the  system 
administrator  except  for  level  0.  Level  0  is  the  lowest  level  on  the  system  and  is  a  special  level 
reserved  for  system  use.  It  is  given  the  name  'SYSTEM'.  A  label  may  contain  from  0  to  1024 
categories.  Relationships  between  labels  are  described  elsewhere  in  this  report  (see  page  89, 
'Mandatory  Access  Control'). 

2.4.3.4.2  Privileges 

System  V/MLS  also  incorporates  a  unique  concept  referred  to  as  a  'privilege'.  A  privilege  is  the 
name  given  to  the  combination  of  a  group  and  a  level  and  is  used  as  an  easy  way  to  move  between 
level/group  combinations.  A  privilege  can  be  thought  of  as  an  instance  of  a  group  at  a  given  level. 
It  is  possible  to  have  separate  privileges  which  are  instantiations  of  a  group  at  different  levels,  and 
each  group,  when  instantiated  at  a  given  level,  is  represented  as  a  distinct  privilege.  Take,  for 
example,  a  discretionary  group  'projA'  that  may  operate  at  several  mandatory  levels.  There  would 
be  one  privilege  made  for  each  level  the  group  projA  may  operate  with.  The  creation  of  privileges  is 
constrained  by  the  clearance  of  the  user  creating  the  privilege  as  well  as  by  the  set  of  levels  currently 
defined  on  the  system.  Privileges  are  then  used  for  both  mandatory  access  decisions  and 
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discretionary  group  access  decisions. 

Each  privilege  has  a  set  of  members  that  may  operate  with  that  privilege.  The  creator  of  a  privilege 
is  the  owner  of  that  privilege.  Only  the  owner  may  add  users  to  the  privilege;  that  can  be  done 
with  the  addgrp  or  addpriv  command,  addgrp  will  add  a  member  to  all  privileges  defined  with  that 
group  provided  the  user  to  be  added  has  the  required  clearance,  addpriv  will  add  a  member  to  a 
particular  privilege  if  the  member  is  authorised  for  the  label  associated  with  the  privilege  (see  page 
66,  'addgrp  and  addpriv  trusted  processes'  for  a  more  complete  description  of  these  commands). 

When  a  subject  creates  an  object,  the  current  operating  privilege  of  the  subject  is  assigned  to  the 
object.  Users  may  change  the  privilege  associated  with  their  files  using  the  chpriv  command. 
Changing  the  label  associated  with  a  file  to  a  level  that  is  not  dominated  by  the  original  is  a 
downgrade.  Reclassification  policy  determines  who,  exactly,  has  the  capability  to  downgrade  a 
specific  file  under  given  circumstances.  The  five  possible  reclassification  policies  are  described  in 
section  7.5  of  the  Trusted  Facility  Manual  for  System  V/MLS  and  range  fi-om  users  operating  as 
root  to  members  of  a  special  discretionary  group  named  secadm  (see  page  53,  'Reclassifying 
Information  ')  to  all  users  of  the  system. 

When  invoking  SGID  files,  the  process  inherits  its  security  label  from  the  user  executing  the 
program  and  its  discretionary  group  fi-om  the  file.  In  other  words,  the  invocation  of  the  SGID 
program  can  not  change  the  current  operating  level  of  the  process.  A  check  is  then  made  to  make 
sure  that  the  resulting  privilege  is  defined  in  the  system. 

The  GID  associated  with  System  V/MLS  objects  is  16  bits  long  and  is  used  to  indirectly  reference  a 
privilege.  Privileges  are  stored  in  the  /mU/lahelt  file  as  machine  dependent  data  structures  that  are 
immediately  usable  by  the  kernel  without  format  conversions.  Machine  dependent  representations 
are  converted  into  machine  independent  canonical  form  whenever  they  are  used  outside  the  kernel. 
In  the  canonical  form  of  a  security  label,  level  and  categories  are  represented  by  numbers.  These 
numbers  are  expanded  as  per  the  /rrds/levtU  and  /mis/ categories  files  before  being  displayed  in 
human  readable  form.  For  all  terminals  the  /mls/cleardev  file  allows  the  storage  of  additional 
information  such  as  device  maximum  and  minimum  labels.  These  device  maximum  and  minimum 
labels  can  then  be  used  to  restrict  the  allowable  levels  of  information  to  be  stored  on  or  retrieved 
fi-om  the  device. 

The  integer  value  assigned  to  a  newly  created  privilege  is  determined  by  incrementing  the  current 
maximum  privilege  value  by  one.  When  the  system  capacity  (60,000)  has  been  used  the  system 
administrator  is  notified  and  determines  the  appropriate  action  to  follow.  Possible  choices  include 
the  failure  to  add  the  new  privilege,  reuse  a  previously  defined  (but  no  longer  in  use)  privilege,  ch- 
’retire’  a  currently  active  privilege  and  then  utilise  the  retired  privilege  number.  As  recommended 
in  the  TFM,  the  reuse  of  a  previously  defined  GID  should  occur  no  sooner  than  one  year  after  the 
privilege  was  retired.  This  waiting  period  minimises  the  potential  for  the  GID  to  still  exist  on  the 
system,  or  for  the  GID  to  exist  on  a  system  backup  that  might  potentially  be  reloaded  onto  the 
system.  If,  in  fact,  a  file  with  a  GID  of  a  removed  privilege  is  loaded  into  the  system  and  the  same 
GID  has  been  used  for  a  new  privilege,  the  file  will  be  associated  with  the  new  privilege.  This  is  the 
reason  that  it  is  impcutant  to  have  a  long  waiting  period  before  a  privilege  GID  is  reused,  and  why 
the  system  administrator  must  be  cautious  when  restoring  files  from  backup  tapes. 

The  /mls/labels  file  is  most  often  accessed  with  the  GID  as  a  search  key.  The  kernel  uses  the 
subject’s  and  object’s  GIDs  to  index  into  the  /mls/lahels  file  and  find  the  associated  security  labels 
when  checking  MAC  access  and  to  find  the  associated  discretionary  group  ID  (DGID)  when 
checking  DAC  access.  Similarly,  when  information  is  displayed  in  a  human-readable  form  (e.g. 
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printed  output),  the  TCB  translates  the  internal  privilege  information  into  a  mandatory  security 
label,  which  is  output  with  the  data. 

The  /mis/ labels  file  is  a  regular  Hie  containing  data  structures  that  map  privileges  to  labels.  Each 
privilege  in  the  file  contains  a  discretionary  group  plus  the  privilege’s  security  label.  The 
/ mis/ labels  file  is  accessible  by  the  kernel  or  a  trusted  process  which  is  SUID  to  root.  New  privileges 
are  always  added  to  the  end  of  the  /rrds/ labels  file  and  a  check  is  made  to  ensure  there  is  not  an 
already  existing  privilege  with  the  same  GID. 

The  following  is  a  description  of  the  format  and  fields  of  the  /mis/ labels  and  /mis/ group  files.  The 
description  of  the  /mls/labels  file  is  a  logical  description  only;  internally  it  is  stored  on  disk  in  a 
binary  format. 

/mls/labels:  <GID>:<DG1D>:<LABEL>:<LABEL  NAME>:<RESERVED> 

GID:  Privilege  ID 

DGID:  Discretionary  Group  ID 

Security  Label:  a  hierarchical  level  and  list  of  non-hierarchical  categories 

Security  Label  Name:  machine  generated  unique  name  for  label  used  to  name  the 
subdirectory  of  a  SECURED  directory  associated  with  this  label 

Reserved:  reserved  for  other  attributes;  network  labels,  ACLS 

/mls/group:  <NAME>:<INFO>:<GID>:<MEMBERS> 

NAME:  This  is  the  name  by  which  the  privilege  is  known.  This  is  the 

name  used  with  newpriv  or  newgrp  commands  to  designate  a 
privilege  or  group. 

INFO:  This  field  is  used  to  contain  various  special  key  words  used  as  flags 

or  indicators. 

GID:  This  is  the  privilege  ID. 

MEMBERS;  This  is  a  comma  separated  list  of  login  names  of  users  who  are 
authorized  to  use  this  privilege/group.  The  first  name  in  this  list 
of  privilege  members  is  the  owner  of  the  privilege. 

The  GID  and  DGID  are  unsigned  short  integers  in  the  range  0  through  60CXX).  It  is  important  to 
note  that  the  GID  and  DGID  identifiers  share  the  same  name/number  space  represented  by  entries 
in  the  / mis/ group  file.  When  the  mkgrp  command  is  executed,  a  GID  is  assigned  for  each  DGID  by 
adding  a  /mls/labels  file  entry  with  GID  =  DGID  and  the  label  set  to  SYSTEM.  When  a  new 
privilege  is  created  with  the  mkpriv  command,  entries  are  made  in  both  the  /mls/labels  file  and  the 
/mls/group  file.  The  new  privilege  receives  a  new,  unique  GID,  and  its  DGID  is  the  same  as  that  of 
the  underlying  group. 

The  /mls/labels  file  contains  entries  for  all  privOeges  in  use  on  the  system.  It  is  a  binary  data  file 
organised  so  entries  can  be  quickly  located  by  kernel  routines  using  the  GID  as  an  index.  The 
/ mls/labels  file  contains  a  hash  table  of  fixed  size.  Slots  are  pointed  to  by  a  hash  of  the  privilege’s 
GID.  Collisions  in  the  hash  table  are  resolved  by  chaining  (i.e.,  the  entry  occupying  the  slot  in  the 
hash  table  points  to  the  next  entry  outside  the  hash  table  whose  GID  hashes  to  the  same  hash 
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index).  Abo,  all  /mU/laheU  entries  with  the  same  discretionary  access  control  group  (DGID)  are 
chained  together.  For  a  pictorial  description  of  how  the  entries  of  the  /mls/labeU  file  are  linked 
together  see  Figure  6. 

The  privilege  data  portion  of  each  /mls/labela  entry  is  a  structure  with  the  following  fields:  GID, 
DGID,  hidden  subdirectory  name  for  this  privilege,  hierarchical  level  of  the  privilege,  the  number  of 
significant  category  words,  and  32  category  words.  Privileges  will  usually  require  many  fewer  than 
32  32-bit  words  to  represent  their  category  set.  Therefore,  indicating  the  number  of  category  words 
that  are  significant  greatly  reduces  the  processing  time  when  working  with  categories.  For  a 
pictorial  description  of  the  fields  of  the  privilege  data  portion  of  the  /mis/labels  entries,  see  Figure  7. 
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2.4.3.4.3  Changing  Subject  Sensitivity  Label  Interactively 

System  V/MLS  incorporates  the  ability  for  any  user  to  alter  the  mandatory  access  control  level  and 
discretionary  group  associated  with  their  session.  This  mechanism  is  invoked  via  the  newpriv 
command,  and  may  only  be  used  to  change  to  a  MAO  level  which  dominates  the  previous  level.  A 
user  executes  a  newpriv  command,  specifying  the  desired  privilege  as  an  argument.  The  user  must 
be  a  member  of  the  selected  privilege.  The  System  V/MLS  TCB  then  compares  this  privilege  with 
the  session’s  clearances  stored  in  the  /mis/ sessions  database.  Should  any  of  these  checks  fail,  the 
newpriv  command  fails  and  returns  an  error  message  and  the  user  remains  at  the  current  privilege. 
If  these  checks  succeed,  then  newpriv  creates  a  new  child  process  and  invokes  a  new  shell  for  the 
user  at  the  new  level.  Additionally,  upon  execution  of  the  newpriv  command,  all  file  descriptors  of 
the  parent  process  are  checked  to  ensure  that  no  violation  of  the  system  security  policy  can  occur. 
If  the  new  level  dominates  the  current  level,  all  the  file  descriptors  are  closed.  The  user  may  then 
operate  at  the  new  level  for  as  long  as  is  desired,  and  terminate  that  session  by  exiting  from  the 
shell.  This  will  release  the  new  shell  only,  and  the  user  will  revert  to  the  shell  in  which  he  or  she  was 
operating  before  issuing  the  newpriv  command.  This  ensures  that  no  information  may  be  passed  in 
violation  of  the  System  V/MLS  security  policy. 

2.4.3.5  Special  User  Authoiiiatiams  on  System  V /MLS 

System  V/MLS  makes  use  of  a  number  of  different  discretionary  access  control  groups,  as  well  as 
specially  defined  mandatory  access  control  labels,  in  order  to  maintain  control  over  different 
elements  of  the  TCB.  Each  of  these,  as  well  as  the  role  it  plays  in  the  overall  security  of  the  system, 
is  discussed  below. 

2.4.3.5.1  Operational  Roles 

In  System  V/MLS  there  are  three  roles  associated  with  performing  administrative  duties  on  the 
system:  Operator,  System  Administrator,  and  Security  Administrator.  A  user  associated  with  one 
or  more  of  these  roles  is  known  as  a  system  officer.  The  duties  involved  in  these  roles  are  peiformed 
with  superuser  (i.e.,  root)  permission.  System  V/MLS  relies  on  additional  security  measures  to 
ensure  that  only  authorised  personnel  are  permitted  to  operate  as  system  officers.  It  should  be 
noted  that  these  roles  can  only  be  enforced  procedurally.  The  system  does  not  enforce  any  kind  of 
separation  or  least  privilege  amongst  roles. 

The  operator’s  duties  deal  primarily  with  the  mechanics  of  running  a  computer  system.  They 
include  the  following: 

-  system  start-up/shutdown 

-  mounting,  unmounting,  and  storage  of  labeled  data 

-  backing  up  and  restoring  files 

-  distribution  of  labeled  hardcopy 

-  ensuring  object  reuse  requirements  on  removable  media 


The  system  administrator’s  duties  deal  primarily  with  configuring  the  system,  and  detecting  and 
correcting  abnormal  conditions.  They  include  the  following: 

-  setting  the  system  time/date 
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-  managing  user  accounts 

•  installing/removing  application  software 

-  maintainmg  correct  permissions 

-  granting  special  authorisations 

The  security  administrator’s  duties  deal  with  maintmning  the  security  of  the  system.  They  include 
the  following: 

-  administering  clearance  information 

-  printing,  creating  and  editing  the  /mis/ levels  and  /mis/ categories  files 

-  maintaining  device  clearances 

-  settmg  up  secured  directories 

-  reclassifying  information 

•  importing  and  exporting  infm-mation 

-  chaiiging  default  protection 

•  configuring  audit  trail  channels 

•  reviewing  audit  trail  data 

•  assuring  the  integrity  of  the  TCB 

-  installing  System  V/MLS 

-  uninstalling  System  V/MLS 


In  order  to  provide  a  more  secure  environment  for  the  system  officers,  System  V/MLS  incorporates 
the  foUowing  changes  to  the  standard  superuser  environment: 

-  No  one  may  login  with  the  user-ID  root.  System  (^ficers  must  first  login  as 
themselves  and  then  s«  to  root.  In  this  way,  all  auditable  actions  performed  by  root 
can  be  traced  back  to  the  individual  user. 

-  The  ability  to  to  root  may  only  be  executed  on  devices  that  have  a  clearance  at  the 
SYSTEM  level.  This  allows  the  capability  to  restrict  system  administrative  actions  to 
terminal  devices  that  can  be  physically  protected. 

-  System  V/MLS  is  delivered  with  a  specified  default  search  path  fen-  program  execution 
by  system  officers. 

-  System  V/MLS  contains  a  security  enhanced  version  of  the  Bourne  shell  for  use  by  the 
system  officers. 

-  System  (^cers,  while  operating  as  root,  can  not  execute  any  program  unless  that 
program  is  labeled  at  the  SYSTEM  label  (i.e.  only  trusted  programs). 
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2.4.3.5.2  System  Software  Integrity 

In  order  to  help  preserve  the  integrity  of  the  system  software,  System  V/MLS  incorporates  a  simple 
integrity  mechanism:  use  of  the  mandatory  access  control  p>olicy  to  assure  that  untrusted  processes 
cannot  write  to  TCB  code  and  data.  All  system  software  (the  kernel,  trusted  processes,  and  any 
other  software  which  the  site  chooses  to  protect)  is  given  the  mandatory  access  control  label 
'SYSTEM'.  SYSTEM  is  defined  to  be  MAC  hierarchical  level  zero  and  is  one  hierarchical  level 
below  the  lowest  mandatory  level  which  is  accessible  by  nonprivileged  users.  When  a  new  user  is 
added  to  the  system,  the  user  is  given  a  minimum  and  maximum  hierarchical  level  at  which  he  or 
she  can  log  on.  In  order  to  modify  a  SYSTEM  level  object,  thb  user  must  either  be  running  a 
trusted  process  which  has  root  authorizations,  or  be  logged  in  at  the  SYSTEM  level.  It  is  intended 
that  only  a  very  few  terminals  and  a  few  trusted  users  on  any  System  V/MLS  system  will  be  given  a 
minimum  clearance  level  of  SYSTEM.  This  prevents  modification  of  TCB  files  by  a  mandatory 
mechanism.  Most  files  which  contain  executable  TCB  code  are  owned  by  the  discretionary  group 
bin.  Most  files  which  contain  non-executable  TCB  files  are  owned  by  the  discretionary  group  sys. 
Membership  in  these  groups  is  restricted  to  trusted  users. 

System  V/MLS  defines  a  system  high  mandatory  access  control  label  in  addition  to  the  system  low 
label,  SYSTEM,  described  above.  This  label,  called  SYSHI,  is  defined  as  the  highest  hierarchical 
mandatory  access  control  level,  with  the  complete  set  of  non-hierarchical  categories  defined  for  the 
site.  SYSHI  is  initialized  when  the  system  switches  from  single  to  multi-user  mode,  and  remains 
constant  while  the  system  is  in  multi-user  mode.  It  is  for  this  reason  that  new  categories  and  leveb 
should  only  be  added  to  the  system  when  it  is  in  single-user  mode. 

One  special  group  exists  directly  in  support  of  a  system  service:  mail.  This  group  is  used  for 
discretionary  access  control  purposes,  in  order  to  allow  several  trusted  processes  which  may  execute 
with  that  group  ID  to  share  resources  while  making  those  resources  inaccessible  to  untrusted  users. 
The  specific  applications  of  this  group  can  be  found  on  page  65,  '/bin/mail'. 

2.4.3.6  Reclassifying  Information 

System  V/MLS  aUows  users  to  change  the  privilege  associated  with  files  and  named  pipes,  provided 
that  the  change  is  to  a  privilege  which  is  currently  defined  on  the  system  and  for  which  the  user  is 
cleared.  During  the  reclassification  process  a  file  can  be  upgraded,  downgraded,  or  the  label  may 
stay  the  same,  in  which  case  the  new  privilege  has  a  different  discretionary  group,  but  the  same 
hierarchical  level  and  set  of  non-hierarchical  categories.  When  a  file  is  upgraded,  the  new  label 
dominates  the  old  label,  and  when  a  file  is  downgraded,  the  new  label  does  not  dominate  the  old 
label.  System  V/MLS  allows  designated  users,  i.e.  user  who  are  allowed  to  downgrade,  to  reclassify 
to  privileges  with  noncomparable  labels. 

System  V/MLS  supports  five  different  reclassification  policies.  They  are  listed  below  in  order  from 
most  restrictive  to  least  restrictive: 

1.  System  administrators  are  the  only  users  allowed  to  reclassify  objects  either  upward  or 
downward. 

2.  System  administrators  and  members  of  the  secadm  group  are  the  only  users  allowed  to 
reclassify  objects  either  upward  or  downward. 

3.  System  administrators  are  the  only  users  aUowed  to  reclassify  objects  either  upward  or 
downward,  and  all  users  can  reclassify  objects  upward. 


Revision  10.4 


-  53- 

overvkw.mm 


(Revised  5/24/91) 


Final  Evaluation  Report  ATfrT  System  V/MLS 
System  Overview 


4.  System  administrators  and  members  of  the  secadm  group  are  the  only  users  allowed  to 
reclassify  objects  either  upward  or  downward,  and  all  users  can  reclassify  objects  upward. 

5.  System  administrators  and  all  users  are  allowed  to  reclassify  objects  either  upward  or 
downward. 

System  V/MLS  is  delivered  to  the  customer  with  the  third  policy  in  effect.  It  is  up  to  the  site 
manager  or  accrediting  authority  to  determine  whether  a  more  or  less  restrictive  policy  is 
appropriate  for  their  site/application,  taking  into  account  the  risks  and  beneHts  of  the  alternate 
policy. 

System  administrators,  when  operating  with  root  capability,  may  reclassify  any  file  on  the  system 
hrom  any  privilege  to  any  other  privilege  provided  the  new  privilege  is  defined  on  the  system.  All 
other  users,  members  of  the  secadm  group  included,  are  subject  to  the  following  restrictions  when 
they  reclassify  information: 

1.  They  must  own  the  object  being  reclassified. 

2.  The  object  being  reclassified  must  be  dominated  by  the  label  of  tht.  currently  operating 
process. 

3.  They  can  not  affect  the  classification  of  objects  that  are  above  their  maximum  clearance. 

4.  They  can  only  do  object  reclassification  on  objects  that  are  within  their  operating  classiflcation 
range. 

The  reclassification  of  objects  is  accomplished  by  using  the  ehpriv  command.  One  can  specify  the 
privilege  name  or  the  label  and  discretionary  group  which  make  up  the  privilege.  For  the 
reclassiflcation  to  be  successful,  the  restrictions  described  above  must  be  satisfied.  If  ordinary  users 
are  not  given  the  reclassification  capability  on  a  given  system  and  a  secadm  group  exists  on  the 
system,  the  user  requesting  reclassification  must  invoke  the  chown  command  to  give  ownership  of 
the  object  to  a  member  of  the  secadm  group  to  do  the  reclassification.  Once  the  reclassification  is 
accomplished,  the  secadm  member  must  return  ownership  to  the  original  user.  Chpriv  requires 
confirmation  of  the  operation  if  any  user  downgrades  a  Hie,  or  if  the  user,  while  operating  at  a  higher 
level  than  the  file,  changes  either  the  label  or  the  discretionary  group  of  the  file.  It  should  be  noted 
that  a  file’s  security  label  can  not  be  changed  if  the  file  is  being  held  open  by  another  process  and 
the  user’s  real  UID  is  not  root.  Also,  only  root  may  change  the  label  of  a  character  special  device. 

After  a  Gle  has  been  reclassified  to  a  lower  classification,  users  at  that  lower  classiEcation  will  still 
not  be  able  to  access  the  file  if  it  resides  in  a  directory  at  a  higher  level.  Therefore,  to  complete  the 
reclassification  process,  the  file  will  have  to  be  moved  to  an  existing  directory  that  has  a 
classification  the  same  as  the  newly  reclassiEed  file.  This  can  be  done  using  the  mvprxv  command. 
The  usual  mv  command  does  not  allow  this  operation  because  of  the  System  V/MLS  MAC  policy  of 
"write  equal  only".  For  the  mvpriv  command  to  succeed: 

1.  the  user  must  have  discretionary  search  and  write  access  to  the  directory  containing  the  file 
and  the  target  directory, 

2.  the  user  must  be  operating  at  a  label  which  dominates  the  labels  of  both  the  source  and  target 
directories,  and 

3.  the  file’s  classification  must  be  identical  to  that  of  the  target  directory. 
mvpriv  requires  conErmation  for  each  file  moved. 
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After  a  file  has  been  upgraded  to  a  higher  classification,  it  still  resides  in  the  lower  level  directory. 
Although  the  user,  while  operating  at  the  file’s  new  classiHcatioii,  would  have  access  to  i'  in  the 
lower  level  directory,  it  is  good  practice  to  keep  files  of  one  classification  together  in  a  directory  of 
the  same  classification.  Also,  while  the  file  is  in  the  lower  level  directory,  it  can  be  deleted  by  the 
owner  while  he  or  she  is  operating  at  the  directory's  lower  level  but  not  when  operating  at  the  file’s 
higher  level.  This  situation  exists  because  of  the  System  V/MLS  'write  equal  only'  security  policy 
and  the  fact  that  creating  and  deleting  files  involves  wn'ites  to  the  containing  directory.  In  order  to 
move  the  file  to  a  directory  at  the  same  level  as  the  reclassified  file,  the  mvpriv  command  is  used.  In 
order  for  the  mvpriv  command  to  be  successful,  the  three  conditions  described  above  must  hold  true. 

2.4.3.7  SECURED  Directories 

System  V/MLS  provides  a  mechanism  to  alleviate  the  problem  of  multi-level  directory  structures. 
The  problem  is  this;  certain  directories  (notably  /dev  and  /tmp)  must  be  accessed  by  all  users  of 
the  system,  whose  authorisations  run  from  system  low  to  system  high.  This  access  by  all  users  can 
result  in  violations  of  the  system’s  security  policy.  The  developers  of  System  V/MLS  refined  a 
mechanism  which  effectively  solves  this  problem.  This  mechanism  designates  a  group  id  at  the  time 
System  V/MLS  is  installed  (by  default,  GID  number  99)  and  designates  that  group  as  SECURED. 
From  then  on,  any  directory  which  has  that  GID  is  treated  specially  by  the  TCB.  The  mechanics 
are  as  follows: 

Within  a  SECURED  directory  are  some  number  of  subdirectories.  When  a  user  logs  in  at  a  given 
security  label,  login  will  create  subdirectories  at  that  label  in  the  SECURED  directories  listed  in  the 
file,  /mte/MldFUea.  This  file  contains  by  default  the  following  directories:  /dew,  /tmp,  /war/ tmp, 
and  / nar / preserve. 

The  same  process  occurs  whenever  a  user  issues  a  newpriv  command  to  change  current  operating 
label.  These  subdirectories  are  created  in  anticipation  that  they  will  be  needed,  although  they  may 
not  actually  be  used.  Mail  subdirectories,  on  the  other  hand,  are  created  by  the  explicit  actions  of 
the  system  administrator  using  the  MailSetup  command.  Therefore,  the  system  administrator 
determines  at  which  security  labels  mail  can  be  received  on  the  system.  It  is  the  subdirectories  of 
SECURED  directories  that  contain  the  files  to  which  non-privileged  users  have  access.  When  a 
non- privileged  user  references  a  file  which  apparently  resides  either  in  a  SECURED  directory  or  in  a 
directory  beneath  a  SECURED  directory,  the  user  is  never  aware  that  the  SECURED  directory 
mechanism  is  controlling  the  traversal  of  the  path  and  eiu'uring  that  he  or  she  is  given  access  only  to 
the  directory  at  the  correct  MAC  label.  To  any  non-privileged  user,  a  SECURED  directory  is 
entirely  transparent.  Namei  is  the  System  V  routine  that  has  been  modified  to  rpcownize  SECURED 
directories  and  skip  over  them  if  the  effective  user  ID  of  the  current  process  L:  not  root  or  the 
current  GID  is  not  'SECURED'.  Since  all  references  to  Files  either  go  through  namet,  or  are  made 
after  access  checks  have  been  made  through  namei,  there  is  no  way  for  the  ordinary  user  to 
circumvent  this  mechanism. 

SECURED  directories  may  only  be  created  by,  and  are  only  visible  to,  the  superuser  and  users 
operating  in  the  group  'SECURED'.  As  an  example  of  how  the  mechanism  operates,  consider  the 
directory  / tmp.  A  user  operating  at  Level  1  attempts  to  create  a  file  called  foo  in  /tmp,  which  has 
been  marked  as  a  SECURED  directory.  The  TCB  recognises  / tmp  as  a  SECURED  directory,  and 
creates  the  user’s  file  in  subdirectory  Ll.S,  instead.  Similarly,  a  user  operating  at  Level  5  who 
attempts  to  create  a  file  called  foo  in  /tmp  may  have  it  placed  in  L5.S.  The  actual  paths  to  the  files 
would  be  /tmp/ Ll.S/ foo  and  /tmp/L5.S/ foo.  Each  of  these  files  would  be  invisible  to  the  other 
user  because  of  the  difference  in  their  MAC  levels,  and  neither  would  note  any  difference  in  the 
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operation  of  the  filesystem. 

System  V/MLS  is  shipped  with  five  SECURED  directories.  They  are  /dev,  /imp,  /usr/tmp, 
/uar/ preserve  and  / usr/ maiL  The  application  of  each  of  these  SECURED  directories  is  explained 
below. 

/ dev  is  the  directory  containing  all  of  the  device  special  files.  Because  the  UNIX  operating  system 
represents  physical  I/O  devices  as  just  another  instantiation  of  files,  this  a  a  convenient  method  of 
organising  all  devices  for  easy  handling  and  access  control.  The  System  V/MLS  approach  to 
handling  devices  is  to  populate  the  /dev  directcuy  itself  with  device  special  files,  and  create  links 
from  the  appropriate  SECURED  subdirectory  to  the  device  special  file  as  needed.  The  contents  of 
/dev  are  therefore  SECURED  subdirectories  for  each  mandatory  access  control  label  in  use  and 
device  special  files  for  each  device  on  the  system.  Because  they  exist  in  the  actual  /dev  directory, 
which  is  marked  as  SECURED,  they  are  unreachable  by  processes  not  executing  with  a  real  or 
effective  UID  of  root  (or  operating  with  the  SECURED  group). 

/imp  and  /usr/tmp  are  merely  temporary  storage  directories,  to  which  all  users  of  the  system  are 
expected  to  have  access.  System  V/MLS  assures  that  no  information  will  be  disclosed  across 
mandatory  access  control  labels  by  its  use  of  SECURED  directories  in  these  locations. 

/usr/ preserve  is  the  directory  which  contains  the  saved  images  of  text  editing  sessions  that  were 
interrupted  either  by  system  crash  or  hang  up. 

/usr/ mail  u  an  employment  of  the  SECURED  directory  mechanism  to  provide  an  easy  way  to 
implement  a  multi-label  secure  mail  system.  The  system  administrator  may  define  the  labels  at 
which  he  or  she  wishes  to  support  mail.  This  is  explained  in  greater  detail  below  (see  page  65, 
'/bin/mail’). 

2.4.S.8  Subject/Object  Access  Decision  Process 

When  a  subject  attempts  to  'open'  an  object  for  later  read/write/execute  access,  it  must  pass  both 
mandatory  and  discretionary  access  checks.  The  access  check  occurs  as  follows: 

The  user  program  executes  an  open  system  call.  The  open  system  call  invokes  the  namet  kernel 
routine,  which  determines  the  location  of  the  requested  object.  Open  then  calls  the  sSaccess  kernel 
routine  for  each  directory  in  the  pathname  as  well  as  the  requested  object.  If  search  access  is  denied 
to  any  directory  in  the  path,  processing  terminates  and  an  error  is  returned®.  SSaccess  invokes 
mls_aecess  to  determine  if  the  subject  is  allowed  mandatory  access  to  the  requested  object. 
Mls_access  utilises  the  routines  mls_dom  and  mls_equ  to  determine  if  mandatory  access  should  be 
granted.  If  mls_access  grants  mandatory  access  to  the  object,  sSaccess  continues  processing  to 
determine  if  discretionary  access  is  permitted.  Upon  completion  of  the  mandatory  and  discretionary 
access  checks,  sSaccess  returns  to  open,  which  generates  an  audit  record  of  the  event  (if  applicable), 
and  then  returns  to  the  user,  indicating  whether  permission  was  granted  or  denied. 

This  basic  procedure  is  followed  for  most  ac -esses  to  objects  with  the  following  exceptions: 


6.  It  should  he  noted  that  successful  directory  accesses  are  not  audited  when  these  accesses  are  private  to  the  TCB  and  are 
neccessary  only  to  compute  access  to  the  resultant  file  for  the  user. 
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— ipc  access  is  granted  via  the  routine  ipcaccess,  which  which  invokes  ndsjdom  and  Tnls_eqii. 
Control  information  for  ipc  objects  is  changed  via  the  routines  IPC_SET  and  IPG_RMID. 

— changing  the  inode  of  a  file  (e.g.  changing  owner  or  file  status  information)  can  occur  via  either 
the  mia_chown  or  the  mls_chmcd  routine.  Both  routines  call  mla_equ  to  determine  if  the  security 
label  of  the  subject  is  equal  to  that  of  the  object  being  changed. 

— a  subject  (process)  is  considered  an  object  when  it  receives  a  signal  from  another  subject.  Signals 
are  sent  via  the  kill  system  call,  which  utilises  mls_kill  to  enforce  restrictions  upon  which  subjects 
may  signal  other  subjects,  and  in  turn  utilises  mlsjtqu  to  determine  that  an  equal  label 
relationship  between  the  subjects  exists. 

— for  all  terminal  devices,  access  controls  are  enforced  when  the  file  is  opened  and  for  each 
read/write  call  to  the  device.  The  open  is  checked  as  previously  described,  while  the  read/write 
access  checks  occur  within  mls_ttyrdmrerr,  using  mlsjdom  and  mls_equ  as  appropriate  for  the 
access  desired. 

2.4.3.9  Auditing 

Auditing  in  System  V/MLS  is  initiated  during  the  transition  from  single-user  to  multi-user  mode. 
The  command  satatart  creates  and  initialises  the  audit  trail  by  invoking  afamap,  which  reads  the  raw 
device  upon  which  each  file  system  exists.  The  system  administrator  must  designate  the  desired 
target  file(s)  for  the  Security  Audit  Trail  (SAT)  to  be  written  to.  The  maximum  sise  of  a  SAT  file 
is  configurable.  The  default  maximum  sise  is  5000  logical  blocks,  where  a  block  can  either  be  512, 
1024,  or  2048  bytes  depending  upon  the  device  type. 

The  audit  trail  file  itself  is  owned  by  root,  has  group  root  and  has  file  permissions  set  to  rw - 

(0600),  meaning  that  only  the  audit  trail  daemon  and  root  have  read/write  access  to  the  file.  In 
addition,  the  audit  trail  is  protected  at  SYSHI.  ff  new  levels  or  categories  have  been  added  to  the 
system  then  aatatart  will  calculate  the  new  SYSHI  and  label  the  audit  trail  appropriately,  when  the 
system  is  brought  into  multi-user  mode. 

There  are  two  ways  in  System  V/MLS  for  an  audit  record  to  be  written;  either  internally  through 
kernel  probe  points  or  directly  through  user-generated  commands.  Kernel  probe  points  function  as 
follows:  for  each  probe  point,  there  is  an  associated  SAT  function  which  collects  all  of  the  necessary 
information  about  that  particular  event  into  a  trace  record.  A  trace  record  is  a  binary  record 
containing  a  header  and  data  block  describing  the  event  to  be  recorded. 

The  trace  records  are  buffered  in  the  aat  pseudo-device.  The  aaUave  daemon  (running  as  root)  reads 
the  trace  device,  /dev/aat/trOOO  and  then  writes  the  trace  records  to  the  audit  trail  file.  The  aat 
device  driver  uses  a  linear  buffer  of  fixed  sise^  and  uses  the  kernel  routine  copyout  to  move 
characters  to  the  aataave  daemon.  If  the  audit  buffer  is  full,  the  process  which  caused  the  record  to 
be  generated  sleeps  until  there  is  room  in  the  buffer.  After  the  next  read  of  the  trace  device,  all 
sleeping  processes  are  awakened  and  any  blocked  audit  records  are  written  to  the  buffer. 

If  no  more  audit  records  can  be  written  because  the  audit  trail  has  become  full,  the  audit  trail 
daemon  wiU  bring  the  system  down  to  single-user  mode  automatically  rather  than  allow  records  to 


7.  AlMK)(i(5ht  tbp  buffer  is  of  fixed  site,  it  is  a  site  confifpirable  option.  The  default  sire  of  this  buffer  is  4096  liytes. 
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be  lost.  Audit  trail  records  which  remain  in  the  buffer  when  the  audit  trail  daemon  is  stopped  or 
killed  are  held  in  the  buffer  while  the  system  is  in  single-user  mode.  When  the  system  is  brought 
into  multi-user  mode  again,  the  data  is  written  to  the  next  audit  trail  file. 

If  the  audit  trail  daemon  ^  annot  write  the  audit  trail  because  of  hardware  or  software  failures,  the 
buffer  will  eventually  become  filled  and  all  user  processes  will  block  upon  executing  auditable  events. 
When  this  happens,  the  only  way  to  restart  the  system  is  to  bring  it  down  to  firmware  mode  via  the 
reset  button  or  the  power  switch.  If  the  reset  button  is  used,  the  core  image  of  the  system  can  be 
saved  and  the  buffer  can  then  be  analyzed  off-line  to  see  what  auditable  events  occurred  just  before 
the  system  crashed. 

Another  method  for  generating  audit  records  is  by  user  commands  through  trusted  processes  writing 
directly  to  the  sat  pseudo  devices.  There  are  16  minor  devices  defined  with  the  sat  device  major 
number.  The  sat  device  with  number  0  is  read  by  the  satsave  daemon.  Minor  devices  1  through  15 
provide  a  user  level  interface  to  the  audit  trail.  This  User  Level  Interface  (ULI)  is  used  to  record 
auditable  events  that  can  only  be  inferred  from  kernel  level  trace  records.  For  example,  the  addition 
of  a  new  user  to  the  password  file  can  be  inferred  from  the  exec  of  an  editor  followed  by  a  successful 
open  of  the  password  file.  Unfortunately,  there  would  be  no  explicit  record  of  what  the 
administrator  did  to  the  password  file.  However,  a  probe  point  in  mkaser  can  easily  record  this 
information.  For  a  list  of  the  ULI  audit  trail  probe  points  see  page  92,  'Audit'.  These  probe  points 
use  the  ULI  to  insert  information  into  the  audit  trail. 

The  user  level  interface  is  divided  into  2  categories:  exclusive  open  and  multiple  open  devices. 
Devices  with  minor  number  1  through  7  are  exclusive  open  and  as  such  can  not  be  opened  by  more 
than  one  process  at  a  time.  Devices  with  minor  number  8  through  15  are  multiple  open  devices.* 
This  distinction  is  made  in  the  sat  driver. 

Auditable  events  on  System  V /MLS  are  allocated  to  one  of  32  audit  channels  based  o  nthe  type  of 
the  event.  Each  of  the  32  channels  has  8  subchannels  which  are  used  to  specify  details  particular  to 
each  channel  or  major  auditable  event.  For  example,  file  access  grants  are  divided  into  those  that 
involve  read  and  write  access;  the  read  vs.  write  distinction  is  recorded  by  writing  read  grant  records 
to  a  different  subchannel  than  that  used  for  write  grant  records.  Channek  are  enabled  and  disabled 
with  an  ioctl  call  on  the  sat  device  with  minor  number  0.  This  \octl  k  restricted  to  the  superuser 
and  only  sets  the  appropriate  channek  when  the  system  k  brought  from  single-user  to  multi-user 
mode. 

The  sat  device  with  minor  number  0  allows  the  following  operations;  reod,  and  ioctl.  The  other  sat 
devices  only  allow  write.  This  does  not  prohibit  the  devices  from  being  opened  for  other  operations, 
but  the  other  operations  are  dkallowed  when  attempted. 

Anyone  granted  access  to  the  operator’s  console  when  the  system  k  in  single-user  or  firmware  mode 
has  the  capability  to  control  and  modify  the  TCB.  Actions  taken  at  thk  time  can  not  be  audited, 
since  the  satsave  daemon  only  runs  when  the  system  k  in  multi-user  mode. 


8.  Ciirrpntly  no  triistpil  prorossos  iiiako  use  of  the  RiiiUipIo  nppn  devirps. 
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2.4.3.10  Trusted  Path 

System  V/MLS  is  capable  of  supporting  a  trusted  communication  path  between  the  user  and  the 
TCB  hardware  and  software.  The  trusted  path  mechanism  varies  among  the  different  system 
conffgurations,  but  it  is  invariably  reliant  upon  the  trusted  process  /bin/getty.  Getty  has  been 
rewritten  so  that  when  it  detects  the  Data  Terminal  Ready  (DTR)  signal  after  DTR  has  been 
inactive,  it  searches  for  all  processes  which  have  that  terminal  port  open  and  kills  them.  Getty  then 
overlays  itself  with  login,  and  the  user  may  proceed  to  log  in  to  the  host.  To  ensure  that  a  trusted 
path  to  the  host  has  been  established,  the  user  must  cause  the  terminal  to  allow  DTR  to  drop;  this 
is  most  effectively  accomplished  by  cycling  the  terminal’s  power. 

In  addition  to  the  trusted  communication  path  at  login,  when  operating  on  the  630  MTG  terminal 
all  trusted  system  commands  that  require  interactive  confirmation  use  a  trusted  path  window.  This 
window  is  created  by  the  trusted  command  and  is  logically  isolated  and  unmistakably 
distinguishable  from  other  paths. 

2.4.3.11  User  Identification  and  Authentication 

System  V /MLS  requires  all  users,  including  privileged  users,  to  identify  and  authenticate  themselves 
before  they  are  allowed  to  access  system  resources.  Users  identify  themselves  by  entering  a  login  ID 
and  authenticate  themselves  by  entering  a  password  which  consists  of  six  to  eight  alphanumeric 
characters.  Identification  and  authentication  information  is  maintained  in  files  within  the  /mis 
directory.  Only  system  administrators  may  gain  access  to  this  directory;  it  is  protected  from  write 
access  by  the  system  mandatory  access  control  policy  (stored  at  SYSTEM  label),  and  is  protected 
from  read  access  by  the  system  discretionary  access  control  policy. 

System  V/MLS  removes  the  sensitive  information  (e.g.  password)  from  the  publicly  readable  files 
/etc/passwd  and  /etc/group,  to  the  protected  files  /mls/passwd  and  /mls/gronp.  These  protected 
files  are  ASCII  files  which  are  referred  to  as  'shadow  files'. 

/mls/passwd  contains  the  following  information  for  each  user: 

-  login  name 

-  encrypted  password 

-  user  ID 

-  group  ID 

-  initial  working  directory 

-  initial  program  to  invoke  upon  login 

/ mis/ group  contains  the  following  information  for  each  group: 

-  group  name 

-  state  indicator  (if  marked  to  be  removed)  and  secadm  flag 

-  group  ID 

-  list  of  all  members  of  the  group 

At  login,  a  user  is  assigned  a  login  privilege.  The  user  may  specify  a  privilege  as  an  argument  to 
login;  if  the  user  and  the  terminal  are  both  permitted  to  operate  with  that  privilege,  it  will  become 
the  user’s  login  privilege.  If  no  privilege  is  specified  at  login  the  user  will  be  assigned  his  minimum 
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allowable  privilege,  provided  that  that  privilege  dominates  the  terminal’s  device  minimum,  and  is 
dominated  by  the  terminal’s  device  maximum.  If  the  user’s  requested  or  default  privilege  is  outside 
the  range  allowed  for  the  terminal,  or  if  the  privilege  does  not  exist,  login  will  fail.  The  minimum 
and  maximum  clearances  for  each  terminal  device  are  kept  in  the  /nds/cleardevTiie.  The  minimum 
and  maximum  clearances  for  users  are  kept  in  the  /mis/ clearances  Gle. 

After  login,  users  may  change  to  any  defined  privilege,  given  that: 

—  The  label  associated  with  the  privilege  is  within  the  user’s  clearance  range. 

—  The  label  associated  with  the  privilege  dominates  the  user’s  current  level. 

—  The  label  is  within  the  range  established  for  the  user’s  login  device. 

—  The  user  is  a  member  of  the  privilege  that  he  or  she  is  attempting  to  change  to. 

For  further  information  see  page  51,  "Changing  Subject  Sensitivity  Label  Interactively". 

When  a  user  logs  in.  System  V/MLS  creates  an  entry  in  the  /mis/ sessions  database.  This  database 
is  actually  a  directory,  which  has  an  entry  (a  file)  for  every  terminal  device  that  a  user  is  currently 
logged  into.  These  files,  in  turn,  contain  information  about  the  user  logged  into  the  terminal,  and 
the  maximum  and  minimum  clearances  of  that  user  for  that  terminal  session.  This  information  is 
used  by  certain  user-level  TCB  commands  (e.g.  newpriv)  in  order  to  ensure  that  a  user  may  only 
operate  within  the  constraints  defined  at  login  time.  The  sessions  database  is  also  used  to  maintain 
a  record  of  terminal  devices  which  may  be  held  open  by  a  user  process  after  a  login  session  has 
completed.  This  record  is  then  used  by  getty  to  find  and  kill  all  such  processes.  This  allows  getty  to 
ensure  a  trusted  path  for  user  logins. 

There  are  two  ways  for  a  user  to  obtain  superuser  privileges:  in  the  first  method,  administrators 
must  first  login  as  SYSTEM  level  users.  This  level  is  less  than  the  nonprivileged  users’  minimum. 
After  an  adminbtrator  enters  the  su  command,  he  must  enter  the  superuser  password  in  order  to 
acquire  administrative  capabilities.  The  second  method  involves  obtadning  physical  access  to  the 
console  terminal  device  when  the  system  is  being  initialized,  and  accessing  the  system  in  single-user 
mode.  This  method  may  not  require  the  use  of  a  password,  depending  upon  the  exact  configuration 
of  the  system;  however,  it  is  expected  that  the  system  console  and  the  CPU  hardware  are  restricted 
to  only  the  most  trusted  users  of  the  system. 

2.4.3.11.1  Adding  Users 

Only  a  systtm  administrator  may  set  up  user  accounts  on  the  system.  The  system  administrator 
uses  the  adduser  command  to  add  users  to  the  system.  The  following  information  is  requested  by 
adduser. 

—  login  ID 

a  string  of  alphanumeric  characters  which  may  be  specified  by  the  system  administrator.  The 
system  generates  unique  user  IDs  (numbers),  each  corresponding  to  a  login  ID.  Login  IDs  are 
recorded  in  the  audit  trail  for  purposes  of  accountability. 

—  default  privilege 

—  minimum  and  maximum  clearances 

—  home  directory 
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—  initial  program  invoked  upon  login 

—  user’s  real  name 

After  the  system  administrator  provides  this  information,  the  automatic  password  generator 
provides  a  choice  of  several  passwords  (up  to  five),  until  the  administrator  selects  one.  By  default, 
passwords  generated  by  System  V/MLS  are  between  six  and  eight  characters  in  length,  and  include 
two  numeric  characters.  The  administrator  has  the  capability  to  override  the  password  generator 
and  can  enter  a  password  of  his  choice.  After  the  administrator  selects  a  password,  adduaer  updates 
the  appropriate  Hies  (i.e.  /etc/pasaiud  and  /mla/paaswd).  Next,  the  administrator  must 
communicate  this  password  to  the  user  in  a  secure  manner.  When  the  user  logs  in  for  the  first  time 
the  automatic  password  generator  provides  a  new  password  for  him.  Guidance  on  these  procedures 
are  provided  in  the  System  V/MLS  Trusted  Facility  Manual  and  the  System  V/MLS  User’s  Guide 
and  Reference  Manual.  Users  may  change  their  passwords  in  the  same  fashion  as  the  system 
administrator;  however,  they  are  not  allowed  to  override  the  password  generator. 

When  the  administrator  is  defining  a  new  user  account,  he  has  the  option  of  assigning  a  minimum 
and  maximum  required  time  period  for  the  user  to  change  his  password.  The  minimum  ensures  that 
the  user  cannot  change  his  password  before  this  time  expires,  and  the  maximum  forces  a  user  to 
change  his  password  after  this  maximum  time  period  expires.  This  process,  known  as  password 
aging,  is  beneficial  in  reducing  the  possibility  that  a  password  can  be  determined  and  used 
uideHnitely  by  an  intruder. 

2.4.3.11.2  Deleting  Users 

In  order  to  remove  a  user  from  the  system,  the  system  administrator  must  either  remove  or  change 
the  ownership  of  all  fdes  belonging  to  that  user.  To  locate  these  files  the  administrator  uses  the  find 
command,  which  has  options  to  remove  or  change  the  ownership  of  the  files.  Find  recursively 
descends  the  directory  hierarchy  for  each  pathname  provided  and  searches  for  the  specified  files. 
Next  the  system  administrator  uses  the  deluser  command  to  remove  the  user  from  the  group, 
password,  and  clearances  files  and  remove  the  user’s  login  directory.  The  administrator  is  advised  in 
the  TFM  to  use  the  rmuser  command  which  invalidates  the  user’s  password  rather  than  completely 
removing  the  user  from  the  system.  Leaving  the  user  in  the  passwd  file  ensures  the  user’s  UID  will 
not  be  reused.  In  this  case  of  a  removed  user,  the  user’s  login  ID  (login  name)  is  not  removed  from 
all  groups  to  which  he  or  she  belonged  (e.g.,  group  file  is  not  modified).  Therefore  system 
administrators  are  ad>ised  to  not  reuse  login  IDs. 

2.4.3.12  Object  Reuse 

System  V/MLS  disallows  scavenging  of  deleted  information  on  the  following  storage  objects: 
directories,  regular  files,  special  files,  named  pipes,  unnamed  pipes,  memory,  shared  memory 
segments,  message  queues,  semaphores,  and  the  630  MTG  buffers.  In  addition,  System  V/MLS 
supports  the  object  reuse  requirements  for  mountable  media  (cartridge  tapes  and  diskettes)  through 
administrative  procedures.  These  procedures  are  explained  in  section  5.6  in  the  System  V/MLS 
Trusted  Facility  Manual. 

2.'i.3.12.1  File  System  Objects 

The  System  V/MLS  TCB  enforces  the  object  reuse  requirements  (as  described  below)  on  the 
following  filesystem  objects:  directories,  regular  files,  and  8p>ecial  files. 
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2.4.3.12.1.1  Disk  Block  Allocation 

System  V/MLS  allocates  disk  blocks  in  a  manner  which  ensures  that  object  reuse  is  not  possible  for 
each  of  the  previously  mentioned  filesystem  objects.  The  system  organizes  and  maintains  a  linked 
list  of  available  disk  blocks.  Each  link  in  the  list  is  a  disk  block  that  contains  an  array  of  free  disk 
block  numbers;  the  last  entry  in  the  array  is  a  pointer  to  the  next  block  in  the  list. 

SSaUoc  causes  the  kernel  to  obtain  an  available  block  from  the  superblock  list.  If  this  block  is  the 
last  available  block  in  the  superblock  list,  the  kernel  uses  this  block  as  a  pointer  to  fill  the  superblock 
list  with  free  disk  block  numbers. 

Then  the  kernel  allocates  a  free  disk  block  and  buffer  for  this  block.  The  kernel  routine  clrbuf  causes 
the  kernel  to  zero  this  buffer.  When  the  user  saves  the  data,  the  kernel  will  copy  the  contents  of  the 
buffer  to  the  associated  disk  block. 

2.4.3.12.1.2  Pipes 

Both  named  and  unnamed  pipes  use  kernel  buffers  to  store  data.  The  TCB  clears  the  buffers  of  any 
previous  data  (see  Disk  Block  Allocation).  A  pipe  may  only  use  a  maximum  of  ten  buffers  at  any 
one  time.  Unnamed  pipes  retrieve  their  inode  and  blocks  from  the  pipe  device  pipefstyp,  and  then 
are  allocated  separate  read  and  write  open  file  table  entries.  Named  pipes  retrieve  their  inode  and 
blocks  from  the  filesystem,  and  then  are  opened  just  like  a  normal  file. 

2.4.3.12.1.3  Memory-Based  Objects 

The  object  reuse  requirement  is  applicable  to  memory-based  objects  such  as  real  memory  pages  and 
shared  memory  segments.  The  object  reuse  mechanism  for  these  objects  is  described  below. 

2.4.3.12.1.3.1  Memory 

System  V/MLS  utilizes  the  demand  paging  mechanism  described  on  page  25,  'Memory  Allocation', 
to  enforce  the  object  reuse  requirement  on  memory.  When  a  process  requires  additional  memory, 
the  grouireg  kernel  routine  determines  the  number  of  new  pages  needed,  and  initializes  the  new 
pages.  This  initialization  involves  marking  the  pages  as  invalid  and  setting  the  'demand  zero  flag'. 
The  demand  zero  flag  indicates  that  the  page  should  be  cleared  when  the  process  first  references  the 
page(s).  When  the  process  references  the  page,  an  invalid  page  exception  occurs  (since  the  page  had 
previously  been  marked  as  invalid),  causuig  the  memory  manager  to  be  invoked.  The  memory 
manager  examines  the  demand  zero  flag,  and  if  set,  clears  the  page  and  marks  the  page  as  valid. 

2.4.3.12.1.3.2  Message  Queues  and  Semaphores 

When  the  system  is  initialized,  the  TCB  designates  specific  areas  of  memory  for  message  queues  and 
semaphore  maps.  These  maps  (or  tables)  are  areas  of  memory  that  contain  pointers  to  message 
queues  and  semaphores.  The  main  kernel  routine  initializes  both  maps  (message  queues  and 
semaphores)  to  all  zeros.  Thereafter,  message  queues  and  semaphores  are  cleared  upon  deallocation 
via  nugctl,  and  semcU.  When  the  msgcti  routine  is  called  with  a  value  of  IPC  RMID,  the  message 
queue  identifier  is  removed  from  the  system  and  the  appropriate  message  queue  map  entry  is 
initialized  to  zeros.  A  process  which  has  been  sleeping  on  an  IPC  message  queue  which  has  been 
deleted  is  awakened  and  returned  an  error.  Thus  the  message  queue  has  been  cleared,  deallocated, 
and  is  ready  to  be  used  again.  System  V/MLS  handles  object  reuse  for  semaphores  in  a  similar 
manner.  The  semctl  kernel  routine  sets  all  semaphores  associated  with  the  given  semaphore 
identifier  to  zero,  if  IPC_RMID  is  set. 
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2.4.3.12.1.3.3  Shared  Memory  Segments 

Shared  memory  is  accessed  (read  and  written)  exactly  the  same  as  regular  memory,  but  controlled 
through  IPC  system  calls.  When  a  shared  memory  segment  is  first  requested,  growreg  is  called  to 
zero  out,  then  allocate  the  memory  to  the  subject  requesting  the  segment.  Thus,  steps  to  eliminate 
object  reuse  are  performed  for  shared  memory  segments  immediately  before  allocation. 

2.4.3.12.1.3.4  630  MTG  Buffers 

The  object  reuse  requirement  is  applicable  to  the  630  MTG  buffers  and  is  described  in  the  630  MTG 
Intelligent  Terminal  section  of  the  report  (see  page  71,  'The  630  MTG  Terminal  Implementation'). 

2.4.3.13  System  Backup  and  Restore 

File  backup  and  restoration  is  considered  a  system  administrator  duty.  Backup  is  done  using  either 
the  sysadm  backup  or  cpio  and  find  commands.  File  restoration  occurs  with  syaadm  restore  or  cpio. 

When  a  file  backup  occurs,  the  GID  is  written  to  the  backup  device  along  with  the  file  data.  The 
GID  is  an  unsigned  short  integer,  which  indirectly  references  the  security  label  using  the  /mls/labels 
file.  Backup  tapes  are  physically  labeled  by  the  system  administrator  with  sticky  labels  representing 
the  sensitivity  level  of  the  tape. 

File  restoration  occurs  by  manually  checking  all  Hies  to  be  restored  against  the  /mls/group.retired 
and  /rrds/paasuid  files  to  ensure  that  the  UID  and  GID  associated  with  the  Hie  are  still  valid. 
Administratively,  GIDs  should  not  be  reused  during  what  would  be  considered  to  be  the  'normal 
life'  of  a  backup  tape.  Files  on  tapes  being  restored  which  are  older  than  this  specified  reuse 
interval  must  be  considered  to  be  unlabeled.  Tapes  containing  Hies  without  valid  labels  must  be 
handled  correctly  by  the  system  administrator.  Such  files  should  be  considered  to  be  SYSHI,  until 
reviewed  by  the  system  administrator.  Files  restored  with  invalid  ownership  information  must  be 
assigned  to  a  new  owner  by  the  system  administrator. 

2.4.3.14  Trusted  Processes 

A  process  must  be  trusted  if  it  is  given  a  privilege  which  permits  it  to  violate  the  system  security 
policy.  There  are  different  ways  in  which  a  process  may  gain  this  privilege;  these  may  be  broken 
down  into  three  categories: 

Those  processes  which  are  relied  upon  to  actively  enforce  the  system  security  policy; 
these  programs  have  intrinsic  privilege,  regardless  of  who  executes  them.  Programs 
which  setuid  to  root,  e.g.  /bin/ps  or  /bin/passwd  fall  into  this  category. 

Those  processes  which  do  not  have  intrinsic  capability,  and  which  must  be  executed  by 
the  system  administrator  or  a  trusted  process  to  take  advantage  of  that  user’s  privileged 
status.  These  are  not  permitted  to  be  used  by  nonprivileged  users,  but  exist  for  the 

system  administrator  to  use  in  order  to  set  up  or  administer  the  system;  e.g. 

/ uar/ bin/ mkuser  or  / usr/ bin/ rmuser. 

Those  processes  which  the  system  administrator  (or  any  nonprivileged  user)  may  execute 
in  the  course  of  day-to-day  operation,  which  must  be  trusted  not  to  abuse  privileges 
when  they  are  executed  by  a  user  who  possesses  them;  e.g.  /bin/cat  or  /bin/ls. 

There  are  numerous  trusted  processes  in  the  System  V/MLS  system.  Programs  which  fall  into  the 

first  of  these  three  categories  (as  well  as  /etc/getty,  /bin/login,  /usr/ bin/layers  which  are  invoked 

by  setuid  to  root  programs  and  thus  run  as  root)  are  discussed  in  some  detail  below.  Programs  of 
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the  second  and  third  type  have  been  evaluated  by  the  team,  and  are  listed  in  Appendix  C  (see  page 
C-1,  "Trusted  Computing  Base  Components').  The  processes  described  below  are  listed  in  roughly 
alphabetical  order,  except  in  those  cases  in  which  several  similar  trusted  processes  have  been 
grouped  together. 

/bin/chpriv.  This  program  is  a  System  V/MLS  extension  of  the  operating  system  which  may  change 
the  group  of  the  object,  or  its  security  label,  or  both,  depending  upon  the  given  argument  string.  If 
the  label  and  group  provided  as  arguments  to  chpriv  do  not  map  to  a  valid  privilege,  an  error  is 
returned.  The  modified  file  attributes  exist  in  the  object’s  inode.  For  further  information  on  the 
reclassification  policies  see  page  89,  'Mandatory  Access  Control'.  This  command  must  be  setuid  to 
root  in  order  to  permit  modification  of  the  inode  and  access  to  the  TCB  data  files  which  provide 
group,  label,  and  privilege  information. 

/bin/df,  /ete/devnm.  This  is  one  program  {/ete/devnmiB  a  link)  which  provides  information  about 
disk  devices.  When  the  program  is  executed  by  the  name  /bin/df,  it  returns  information  about 
space  available  on  disk  devices.  It  has  options  which  allow  it  to  search  raw  devices  and  print  total 
blocks  used  as  well  as  blocks  available.  When  executed  by  the  name  /ete/devnm,  it  provides  a 
mapping  between  file  system  names  (such  as  /usr)  and  the  actual  physical  devices  upon  which  they 
are  mounted.  Neither  program  has  any  security-relevant  function,  but  because  of  its  ability  to 
access  raw  devices,  it  must  be  setuid  to  root. 

/bin/xpcs:  This  is  a  utility  which  provides  a  report  on  the  status  of  interprocess  communications 
throughout  the  system.  Under  System  V/MLS  ipct  provides  information  on  all  the  objects 
dominated  by  the  user.  ipe$  is  capable  of  reporting  information  about  message  queues,  shared 
memory,  and  semaphores.  In  order  to  obtain  this  information,  it  looks  directly  into  /dev/kmem,  and 
therefore  must  be  setuid  to  root. 

/bin/labelt:  This  is  a  utility  program  which  formats  and  prints  any  of  the  security  labels  defined  to 
the  system  in  a  human-readable  format.  This  command  is  used  to  determine  the  security  label  of 
any  file  to  which  an  invoker  has  mandatory  access,  the  invoker’s  current  operating  security  label, 
the  security  label  associated  with  any  given  privilege,  or  the  discretionary  group  of  an  object.  In 
addition,  this  command  is  also  used  to  construct  labels  fi’om  given  level  and  category  names.  The 
command  parses  its  arguments  to  determine  what  information  is  to  be  returned;  it  then  accesses  the 
TCB  data  files  /mis/ labels,  /mis /clearances,  /mis/ levels,  and  /mis/ categories  in  order  to  gather  the 
information  it  needs  to  return  to  the  user.  The  command  verifies  that  the  user  is  authorised  to  see 
the  information,  and  will  print  an  error  message  if  the  user  is  unauthorised  to  see  the  data 
requested.  Because  of  its  need  to  access  TCB  data  files,  labels  must  be  setuid  to  root. 

/bin/login:  This  is  the  program  which  identifies  and  authenticates  users  on  the  system,  login  has 
several  functions: 

-  read  the  user’s  password  and  compare  it  ag^st  the  encrypted  password  stored  in 
/  mis/  passwd; 

-  compare  the  user’s  requested  or  default  login  security  label  with  entries  in  the 
/mls/gronp  and  /mis/ clearances  files  in  order  to  verify  that  the  user  is  initiating  a 
session  within  his  or  her  authorised  range  of  security  labels. 

-  check  the  requested  or  default  login  security  label  against  the  file  /mls/cleardev,  which 
contains  device  maximum  and  minimum  security  labels. 
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-  determine  terminal  type  from  the  entry  in  /mis/ cleardev. 

-  determine  (again  from  information  in  /tnls/ cleardev)  what  if  any  special  port  handling 
programs  may  be  required  for  this  device  (e.g.,  SSOinii).  If  such  a  handler  is  required, 
then  login  forks  a  copy  of  the  handler  and  releases  the  terminal  to  its  control.  If  no 
handler  is  required,  login  forks  a  copy  of  the  user’s  shell,  as  specified  in  /mls/passwd, 
or  /hin/sh  if  none  is  specified,  and  releases  the  terminal  to  the  user. 

/bin/mail,  /usr/bin/mailx,  and  /usr/bin/mailekeek  All  of  these  programs  exist  in  support  of  the 
multi-level  secure  mail  system  which  operates  under  System  V/MLS.  mail  and  mailx  are  similar  in 
that  they  provide  a  user  interface  through  which  mail  can  be  sent  to  or  received  from  another  user. 
Each  of  them  sets  its  group  ID  to  maw  iu  .irder  to  access  mail  files  which  are  kept  in  the  / tier/ mail 
directory.  The  primary  differences  between  the  two  are  features:  mail  is  the  'standard*  Unix 
System  V  mailer.  It  lacks  many  of  the  more  sophisticated  features  of  mailx.  mailx  allows  far  greater 
flexibility,  and  incorporates  a  number  of  extensions  which  facilitate  its  use  as  a  mailer  for  use  in 
sending  mail  across  networks  (although  networks  are  not  included  in  the  evaluated  configuration). 
Traditional  UNIX  msul  systems  are  quite  simple;  a  directory  (normally  /usr/mail)  is  set  up  and  its 
permission  bits  set  so  that  only  users  operating  with  the  group  ID  of  mail  are  allowed  access.  Each 
user’s  mail  is  kept  in  a  separate  file  in  that  directory.  The  individual  mail  files  are  owned  by 
individual  users,  /usr/mail  is  a  SECURED  directory;  because  of  this,  it  has  been  possible  to 
implement  a  multi-level  mail  facility  with  virtually  no  modification  to  the  underlying  mail 
mechanism.  Since  /bin/mad  was  not  modified  and  given  root  privilege,  read-down  of  mail  is  not 
possible.  The  system  administrator  must  define  a  mail  subdirectory  for  each  label  at  which  the 
system  is  to  support  mail,  but  other  than  that,  the  mail  system  functions  at  multiple  labels  quite 
transparently. 

In  practice,  the  multi-level  secure  mail  system  occasionally  inconveniences  users,  who  may  not  realise 
that  they  were  sent  mail  at  a  label  within  their  clearance  range,  but  above  the  clearance  of  their 
current  terminal  session.  To  alleviate  this  potential  problem,  the  system  developers  provided  a 
mailbox-checking  facility,  mailcheck  is  a  System  V/MLS  extension  which  allows  users  to  determine 
whether  there  is  mail  in  mailboxes  at  any  or  all  of  their  other  labels,  mailcheck  notifies  the  user  of 
mail.  If  the  user  has  mail  at  levels  dominated  by  his  or  her  current  operating  level,  mailcheck  prints 
the  security  label  of  each  level  in  human-readable  form,  although  does  not  print  the  contents  of  the 
mes8age(8).  If  the  user  has  mail  at  a  level  not  dominated  by  the  user’s  current  level  (but  within  the 
user’s  clearance  range),  the  string  '(and  other  levels)'  appears  in  the  output.  This  message  does  not 
convey  any  information  about  the  actual  me8sage(8)  or  about  the  level  of  the  mes8age(8),  other  than 
the  fact  that  at  least  one  other  message  exists  within  the  user’s  clearance  range.  It  is  a  somewhat 
incomplete  implementation  of  a  secure  mail  facility  in  that  it  permits  a  downward  flow  of 
information.  This  is  acceptable  in  a  Bl  implementation,  mailcheck  does  not  report  mail  detected  in 
a  mailbox  above  the  user’s  maximum  clearance.  As  an  option  and  a  convenience,  mailcheck  wiU 
forward  mail  from  lower  labek  up  to  the  current  operating  label  in  order  for  a  user  to  read  mail  of  a 
lower  level.  In  order  to  access  all  users’  mail  files,  the  mailcheck  program  must  be  setuid  to  root. 

/bin/newgrp:  This  program  allows  a  user  to  change  his  or  her  discretionary  access  group  after 
logging  in,  thus  eliminating  the  need  to  log  off  and  relogin  at  the  new  group.  It  checks  the 
/mis/ group  file  to  determine  the  user’s  authorised  groups;  i.e.,  that  the  requested  change  is  to  a 
valid  group  and  there  is  a  privilege  in  that  group  (of  which  the  user  is  a  member)  corresponding  to 
the  user’s  current  operating  label.  A  new  shell  is  then  created  with  the  user’s  real  and  effective 
group  id  changed  to  the  target  group;  the  new  values  are  used  in  mediating  access  control  decisions. 
If  the  newgrp  command  is  invoked  as  /bin/newgrp,  then  the  user’s  original  shell  remains  in  the 
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background,  and  is  reactivated  upon  termination  of  the  new  shell.  This  is  done  by  the  fork  and  exec 
system  calls.  However,  if  newgrp,  the  shell  built-in,  is  invoked,  then  the  current  shell  is  overlaid 
with  a  new  shell.  The  shell  built-in  only  uses  the  exec  system  call.  In  order  to  modify  the  user’s 
group  ID  values  (which  are  stored  in  memory-based  tables),  the  program  must  be  setuid  to  root. 

/bin/ nevupriv:  This  prograun  allows  a  user  to  change  his  or  her  operating  privilege.  It  is  discussed  in 
detail  elsewhere  in  this  document  (see  page  51,  "Changing  Subject  Sensitivity  Label  Interactively"). 

/bin/pasawd:  This  is  the  password  setting  and  changing  program  in  System  V/MLS.  It  includes 
System  V/MLS  extensions,  among  which  are  the  ability  to  define  a  minimum  password  length,  the 
ability  to  require  numeric  characters  in  addition  to  alphabetics,  and  the  ability  to  generate  pseudo¬ 
random  passwords;  all  of  these  features  are  enabled  in  the  standard  configuration  of  System  V/MLS. 
paaawd  generates  pronounceable  random  passwords  which  may  be  tailored  to  some  extent  by  the 
user,  based  upon  the  value  stored  in  the  shell  variable  PASSWDOPTS,  which  determines  ordering 
of  syllables  between  alphabetics  and  numerics.  The  system  administrator  has  the  ability  to  set  any 
user’s  password,  and  may  explicitly  override  the  random  password  selection  mechanism.  Since 
paaawd  modifies  the  file  /mla/paaawd,  it  must  be  setuid  to  root. 

/bin/pa;  The  pa  command  displays  information  about  the  status  of  processes  on  the  system.  When 
executed  by  the  system  administrator,  pa  is  capable  of  displaying  the  status  of  all  processes  on  the 
system;  when  executed  by  any  other  user,  it  will  only  display  information  about  processes  owned  by 
that  user  and  dominated  by  the  label  of  the  process  which  invoked  the  pa  command,  pa  must  run 
setuid  to  root  in  order  to  access  the  device  /dev/mem,  from  which  it  extracts  process  information. 

/6tn/su;  This  is  the  command  which  allows  a  process  to  assume  the  real  and  effective  UID  of  the 
superuser  (if  the  superuser  password  is  known),  or  of  any  other  user  of  the  system,  provided  one 
knows  the  password  for  the  target  login  ID  and  is  operating  at  the  SYSTEM  label,  or  is  currently 
operating  as  superuser,  an  is  the  only  way  of  becoming  root  (superuser)  on  System  V/MLS,  and  ait 
to  root  is  restricted  to  terminals  which  have  a  device  minimum  label  of  SYSTEM.  Users  must  be 
operating  at  the  SYSTEM  label  in  order  to  au  to  root  or  any  other  user.  Since  no  untrusted  user  is 
expected  to  be  able  to  login  at  the  SYSTEM  label  (System  V/MLS  uses  this  mechanism  in  order  to 
help  ensure  the  incorruptibility  of  system  code),  very  few  user  terminals  should  have  this  capability. 
Because  au  must  be  able  to  create  a  process  which  has  a  UID  of  root,  it  is  a  setuid  to  root  program. 

/etc/getty:  This  program  exists  for  every  terminal  line  until  a  user  attempts  to  login.  Each  getty 
resets  its  process  group  using  the  aetpgrp  system  call,  calls  open  for  a  particular  terminal  line,  kills 
any  background  processes  that  have  the  terminal  port  open,  and  sleeps  until  the  system  senses  a 
connection.  Upon  receiving  a  login  name,  getty  overlays  itself  with  login. 

/uar/ bin/addgrp,  /uar/ bin/addpriv:  These  programs  are  System  V/MLS  utilities  which  allow  the 
owner  of  a  group  or  privilege  to  add  members  to  them.  These  commands  control  much  of  the 
discretionary  access  control  mechanism  which  exists  in  System  V/MLS.  In  order  for  a  user  to  grant 
discretionary  access  to  a  fde,  the  user  can  create  a  group  or  privilege  (using  the  mkgrp  or  mkpriv 
command  described  below),  and  set  the  group  or  privilege  of  the  file  to  the  new  one  by  using  the 
chgrp  or  chpriv  commands.  The  user  may  then  change  the  permission  bit  settings  on  the  file  (via 
the  chmod  command),  granting  the  desired  access  to  group  members.  The  user  can  then  add 
members  to  the  group  or  privilege  with  the  addgrp  or  addpriv  commands.  Operation  of  the 
commands  is  as  follows:  they  accept  as  arguments  the  name  of  the  group  or  privilege  (if  given  a  label 
and  group,  addpriv  constructs  the  privilege  name  from  that  information),  and  the  name  of  a  user  to 
be  added  to  that  group  or  privilege.  The  superuser  may  add  members  to  any  group  or  privilege, 
regardless  of  its  ownership.  Because  these  commands  manipulate  the  shadow  group  file, 
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/ mis/ group,  they  must  be  setuid  to  root  programs. 

/usr/bin/SSOinit  This  program  is  used  to  initialise  and  verify  630  MTG  terminals.  This  is 
accomplished  by  downloading  the  ehkSSO  program,  which  verifies  the  state  of  the  terminal,  and  if 
these  checks  succeed,  by  downloading  ftv.mods  creates  a  secure  smart  terminal  environment.  The 
details  of  this  program  are  discussed  elsewhere  in  this  document  (See  page  72,  "The  630init 
Process’). 

/usr/ bin/at,  /usr/ bin/ batch,  /usr/bin/crontab:  These  programs  are  used  to  schedule  execution  of 
programs  at  a  later  time  or  date,  or  defer  execution  of  programs  until  the  system  load  decreases. 
Specifically,  at  and  crontab  allow  a  user  to  dictate  a  time  and  date  for  execution  of  a  command 
sequence,  batch  submits  a  job  for  processing  as  soon  as  system  load  permits  its  execution.  Jobs  sent 
via  batch  go  into  a  different  CPU  queue,  and  have  a  lower  execution  priority  than  ordinary 
interactive  processes.  All  of  these  programs  may  be  restricted  by  the  use  of  files  which  will 
specifically  allow  or  deny  access  to  users  identified  by  the  system  administrator.  These  programs 
require  the  ability  to  setuid  to  any  user  ID  which  may  submit  a  job  for  processing,  so  all  must  run 
setuid  to  root.  In  System  V/MLS  the  ability  to  execute  programs  through  these  channels  is 
restricted  to  a  handful  of  administrative  IDs. 

/usr/ bin/ clearances:  This  is  a  System  V/MLS  utility  which  informs  a  user  either  of  his  or  her 
maximum  and  minimum  authorized  security  labels  on  the  system,  or  of  the  current  session 
maximum  and  minimum.  If  executed  by  the  superuser,  clearances  is  capable  of  reporting  all  of  the 
clearances  available  on  the  system,  or  the  clearances  for  any  user,  or  which  users  have  access  to  a 
particular  clearance.  Because  this  program  accesses  the  shadow  group  file  Md  the  /mis/ clearances 
file,  it  must  be  setuid  to  root. 

/usr/b%n/ dominates:  This  program  is  used  to  compare  two  security  labels  passed  as  arguments.  If 
the  first  label  dominates  the  second  label  then  the  character  “0”  is  written  to  standard  output  and 
the  exit  status  is  0.  Otherwise,  the  charaM:ter  “1”  is  written  to  standard  output  and  the  exit  status 
is  1.  Since  dominates  accesses  the  /mls/calegories  and  /mls/levels  files,  it  must  be  setuid  to  root. 

/usr/bin/dmdld:  The  downloading  of  software  can  only  be  initiated  by  the  trusted  process  dmdld. 
The  dmdld  program  is  discussed  in  detail  elsewhere  in  this  document  (See  page  78,  "Downloadable 
Software").  Since  it  makes  use  of  the  JBOOT  ioctl,  (which  is  restricted  to  root),  dmdld  must  be 
setuid  to  root. 

/usr/bin/lp,  /usr/ bin/ cancel:  Ip  arranges  for  the  named  file  and  associated  information  (collectively 
called  a  request)  to  be  printed  by  a  line  printer.  Ip  associates  a  unique  ID  with  each  request,  cancel 
cancels  line  printer  requests  that  were  made  by  the  Ip  command.  Specific  requests  may  be  canceled 
by  passing  the  request  ID  as  a  command  line  argument  to  cancel.  Both  of  these  programs 
accomplish  their  tasks  by  sending  messages  to  the  Ipsched  daemon  by  writing  to  the  named  pipe 
/usr/ spool/lp/ FIFO.  Since  the  pipe  is  at  the  system  level,  both  programs  must  be  setuid  to  root. 
The  cancel  command  immediately  resets  its  UID  to  Ip  and  GID  to  bin,  to  enable  it  to  write  to  the 
pipe  without  having  to  continue  to  run  as  root.  However,  the  Ip  command  must  continue  to  run  as 
root  since  it  needs  to  not  only  write  to  the  pipe,  but  also  to  read  files  of  various  levels  (the  files 
being  printed).  Ip  uses  the  access(2)  function  to  ensure  that  the  user  is  authorized  to  read  the  file  for 
printing. 

/usr/lib/lpadmin:  The  Ipadmin  command  is  used  to  administer  printers  within  the  LP  subsystem. 
Its  three  usages  are  to: 
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-  set  the  system  default  destinations  which  Ip  checks  when  no  destination  has  been 
explicitly  specified. 

-  remove  a  printer  from  the  LP  subsystem  by  deleting  the  request  directory,  the  qstatus 
entry,  and  the  entries  associated  with  the  destination. 

-  change  attributes  of  a  printer  (e.g.  change  pstat  entries  to  reflect  that  the  printer  is 
hardwired,  establish  a  new  interface  for  a  printer,  select  a  model  interface  program  for  a 
printer,  associate  a  new  device  with  a  printer). 

Ipadmin  must  be  set  aid  to  Ip  in  order  to  write  into  /uar/apool/tp. 

/usr/bin/Ugrp,  /usr/bin/lspriv:  These  commands  list  membership  of  all  groups  or  privileges  to 
which  the  user  belongs  (whether  the  user  created  the  privilege  or  group  or  was  added  to  the  privilege 
or  group).  In  addition,  lapriv  can  Ust  for  superuser  all  privileges  that  a  given  user  is  a  member  of. 
/uar/bin/lagrp  is  a  link  to  the  program  contained  in  /uar/bin/lapriv.  Because  the  program  must 
access  the  / mla/ group  file,  it  must  be  setuid  to  root. 

/uar/ bin/lpatat  This  program  provides  a  mechanism  through  which  all  users  may  inquire  about  the 
status  of  the  printers  connected  to  the  system.  Various  parameters  determine  what  status 
information  should  be  printed;  specifically,  one  may  determine  whether  a  given  printer  is  currently 
accepting  requests,  is  enabled,  has  output  requests  queued,  etc.  Because  Ipatat  retrieves  its 
information  from  tables  in  memory  to  which  access  is  restricted,  it  must  be  setuid  to  root. 

/uar/bin/mkgrp,  /uar/bin/mJtpriv.  These  are  programs  which  allow  a  user  or  system  administrator 
to  define  new  discretionary  groups  or  privileges  on  the  system.  If  either  command  is  executed  by  a 
non-privileged  user  in  order  to  create  a  new  group,  that  user  owns  the  group,  and  may  add  members 
to  and  delete  members  from  it  (if  the  system  administrator  creates  a  group  or  privilege,  the  Hrst 
member  he  adds  is  considered  to  be  the  owner  of  the  group  or  privilege).  The  group  owner  may  also 
create  privileges  based  on  the  group  via  the  mkpriv  command.  A  typical  usage  sequence  would  be  as 
follows;  userA  wishes  to  establish  a  privilege  called  FUNNY,  with  members  Larry,  Moe,  and  Curly, 
operating  at  the  label  SECRET.  First,  the  user  would  establish  a  discretionary  group  called 
FUNNYGRP,  using  the  mkgrp  command.  Then,  using  the  mkpriv  command  and  specifying  label 
SECRET  and  group  FUNNYGRP,  userA  can  create  the  privilege  FUNNY  (and  explicitly  add 
Larry,  Moe  and  Curly  to  its  membership  as  it  is  created).  The  privilege  FUNNY  will  then  exist  at 
the  desired  label  and  with  the  desired  members.  Both  of  these  commands  (mkgrp  and  mkpriv) 
manipulate  the  shadow  group  and  privilege  Bles,  and  must  therefore  run  setuid  to  root. 

/uar/ bin/modpriv.  This  utility  modifies  the  /mia/ group  file  entry  for  a  specified  privilege.  It  may 
be  invoked  by  superuser  or  by  the  owner  of  the  privilege.  Presently  the  only  option  supported  is  the 
-r  option,  which  allows  the  user  to  rename  the  specified  privilege.  Since  modpriv  modifies  the 
/mla/ group  file,  it  must  be  setuid  to  root. 

/ uar/ bin/ modgrp:  This  utility  allows  the  transfer  of  ownership  of  a  group  to  another  user.  Only  the 
current  owner  of  a  group  (or  superuser)  can  transfer  ownership  of  that  group.  When  this  occurs, 
ownership  of  all  privileges  associated  with  the  specified  group  are  adso  automatically  transfered  to 
the  new  user.  Since  modgrp  modifies  the  /rrda/ group  file,  it  must  be  setuid  to  root. 

/uar/bin/mvpriv.  This  is  a  utility  which  allows  a  user  to  move  a  file  from  one  directory  into  another 
directory  (with  a  different  label  than  the  first  directory)  which  has  the  same  label  as  the  file.  This  is 
necessary  in  some  circumstances  due  to  the  ordering  of  the  filesystem.  When  moving  a  file  between 
directories  of  equal  labels,  the  standard  mv  command  can  be  used.  However,  System  V /MLS  MAC 
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p)olicy  prohibits  this  command  from  moving  Hies  between  directories  of  differing  labels;  for  this, 
mvprtv  must  be  used.  The  label  of  the  file  being  moved  must  be  the  same  as  the  label  of  the  target 
directory.  Also,  the  name  of  the  file  can  not  be  changed  (as  it  can  with  mv)  when  moved  via  mvpriv. 
mvpriv  is  setuid  to  root  since  it  needs  to  violate  MAC  policy  by  writing  to  at  least  one  directory 
with  a  label  different  from  the  label  of  the  invoking  process. 

/uar/bin/delgrp,  /usT/bin/delpriv:  These  two  utilities  delete  members  from  a  group  or  privilege. 
Only  the  owner  of  a  group  (or  superuser)  can  delete  members  from  that  group.  When  this  occurs, 
the  members  are  also  automatically  deleted  from  all  privileges  that  include  the  specified  group. 
Similarly,  only  the  owner  of  a  privilege  (or  superuser)  can  delete  members  from  that  privilege"  The 
owner  can  delete  members  of  a  specific  privilege  or  membe’'s  of  all  privileges  that  include  a  specified 
group  or  a  specified  label  (with  the  owner’s  current  operating  group). 

/usr/bin/rmgrp,  /usr/bin/rmpnv:  These  two  utilities  remove  groups  or  privileges  from  the  system 
data  files.  Upon  deletion  from  the  system,  the  group  and  privilege  numbers  are  set  aside,  for 
possible  reuse  at  a  later  time.  The  procedure  for  reuse  of  privileges  is  detailed  in  the  System  V/MLS 
Trusted  Facility  Manual,  which  advises  against  doing  this;  it  also  lists  procedures  which  may  be 
followed  to  ensure  that  any  reuse  of  group  or  privilege  IDs  will  not  contravene  the  system  security 
pmlicy.  Both  of  these  programs  manipulate  TOB  data  files,  and  therefore  must  be  setuid  to  root. 

/usr/ lib /enable,  /usr/ lib/ disable:  The  enable  command  enables  a  printer  (supplied  as  an  argument 
to  the  command)  to  print  Ip  requests.  Conversely,  the  disable  command  is  used  to  disable  a  printer. 
Print  requests  will  be  queued  for  the  printer,  and  printed  when  the  printer  is  enabled  again. 
enable/disable  requests  are  communicated  to  the  Ipsched  daemon  via  the  /usr/ spool/lp/ FIFO 
named  pipe.  Since  the  pipe  is  at  the  SYSTEM  level,  both  commands  must  be  setuid  to  root.  These 
commands  may  be  executed  by  the  user  while  operating  at  amy  level.  They  both  immediately  reset 
the  GID  to  bin  at  the  SYSTEM  level,  and  UID  to  Ip  so  that  they  may  write  to  FIFO  without 
having  to  continue  to  run  as  root. 

/usr/lib/mailx/rmmad:  This  is  a  program  which  allows  a  user  to  remove  an  empty  ,..ail  file  from  a 
mail  subdirectory.  In  order  to  do  this,  it  must  be  setgid  to  mail. 

/ usr/ lib/ mv_dir.  mv_dir  is  called  by  mv  if  the  object  to  be  moved  is  really  a  directory.  mv_dir  only 
allows  a  user  to  rename  a  directory  within  its  parent  directory.  Directories  can  not  be  moved  from 
one  directory  to  another  via  mv  dir.  mv_diT  needs  to  be  setuid  to  root  in  order  to  do  a  move  of  a 
directory. 

/usr/lib/sa/sadc:  The  sadc  program  samples  and  saves  system  activity  data  by  reading  /dev/kmem 
directly.  This  data  is  statistical  information  (e.g.  number  of  process  switches  per  second,  number  of 
forks  per  second  etc..)  To  gather  this  information,  it  must  be  setuid  to  root.  The  saved  data  is  used 
by  sar(l)  to  generate  formatted  system  activity  reports. 

/usr/ spool/lp/interface/SSlO  and  /usr/lib/pgmark:  The  5S10  interface  script  is  called  by  Ipsched 
to  derive  the  proper  label  (oi>erating  label  of  user)  for  the  header  and  trailer  banner  pages  of  the 
hardcopy.  The  5SI0  script  calls  the  labels  command  to  determine  the  correct  label  for  the  request. 
Page  sensitivity  labels  can  be  added  by  pgmark.  The  sensitivity  labels  replace  the  top  and  bottom 
two  lines  with  the  appropriate  label  (operating  label  of  user).  If  the  label  is  too  long  for  the  top  and 
bottom  label  areas,  a  ULI  record  reporting  the  "partial"  disabling  of  labels  at  the  top/bottom  of 
pages  is  cut  and  the  following  string  is  substituted  for  the  label: 

**  security  label  for  privilege  <privname>  too  long  to  print  **. 

The  long  label  WILL  be  printed  in  the  banner  page,  although  it  is  likely  that  multiple  pages  will  be 
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needed  to  hold  each  banner  ps^e.  Printer  requests  should  be  passed  through  a  filter  such  as  pr 
which  inserts  blank  lines  at  the  top  and  bottom  so  no  data  is  lost  from  the  hardcopy.  Both  are 
invoked  with  UID  of  Ip  and  GID  of  bin  in  order  to  access  files  private  to  Ip. 
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2.4.4  The  630  MTG  Termmal  Implementation 
2.4.4.1  Overview 

The  630  MTG  (Multi-Tasking  Graphics)  terminal  supports  two  to  eight  logical  connections  to  each 
of  two  hosts  multiplexed  over  a  single  tty  connection  each;  one  data  channel  for  each  host  window, 
plus  a  control  channel  (channel  0)  reserved  for  direct  communications  between  the  host  process 
layers  and  the  630  MTG  terminal.  Several  630  MTG  terminals  can  be  hooked  to  a  host 
simultaneously.  When  a  window  is  created,  a  data  channel  is  associated  with  it.  The  xt  driver 
(device  driver  for  the  virtual  terminals)  multiplexes  I/O  via  the  xt  devices  onto  the  real  tty 
associated  with  the  layers  process  managing  the  host  end  of  the  windowing  protocol-  The  host 
resident  application  programs  (e.g.,  shell)  are  unaware  that  they  are  executing  in  a  layers 
environment;  each  xt  device  appears  to  a  host  resident  untrusted  application  to  be  a  regular  tty 
device. 

The  630  MTG  terminal  can  be  used  by  a  user  or  by  a  system  administrator,  but  is  not  suitable  for 
use  as  the  system  console.  This  is  because  it  is  possible  to  lose  messages  since  processes  which  write 
error  messages  to  the  system  console,  like  login,  do  not  follow  the  xt  protocol. 

On  the  host  side  of  the  physical  connection,  there  is  an  xt  driver  which  multiplexes  each  data 
channel’s  I/O  onto  the  real  tty  driver  associated  with  the  layers  process,  managing  that  tty.  On  the 
630  MTG  side  of  the  physical  connection,  a  firmware  demultiplexer/controller,  demux,  receives  the 
communication  from  the  host.  Demux  handles  control  information  (such  as  download  initiation 
signal)  as  well  as  passing  data  to  the  appropriate  window. 

The  630  MTG  terminal  has  routines  in  its  firmware  which  are  called  upon  when  a  user  requests 
certain  terminal  functions  such  as  create  a  window  and  cut  data  from  a  window.  A  "630  process" 
has  no  relation  to  a  UNIX  process  running  on  the  host.  There  is  only  one  process  on  the  630  MTG. 
That  process  in  turn  supports  "threads".  Threads  may  be  thought  of  as  streams  of  execution 
contained  entirely  within  the  630  process.  The  630  process  creates  and  deletes,  schedules  and 
maintains  data  structures  for  all  threads  on  the  terminal.  Each  window  has  one  and  only  one  thread 
called  wproc.  Each  thread  has  its  own  process  structure  (which  contains  a  field  for  that  thread’s 
security  label),  and  shares  text  and  globals  (neither  containing  user  data)  with  every  other  thread. 
Threads  do  not  have  their  own  address  space.  Global  variables  shared  among  threads  exist  within 
the  address  space  of  the  630  process.  Threads  do  however  have  their  own  local  variables  (such  as 
program  counters)  and  store  them  in  their  own  private  stacks.  A  thread’s  private  stack  is  pointed  to 
by  the  process  structure.  Process  structures  store  the  state  they  are  in  (e.g.,  RUN)  and  exist  on  a 
linked  list  of  process  structures.  When  a  thread  is  executing,  data  stored  in  other  threads  is  not 
available  to  the  executing  thread;  although  memory  which  that  data  might  point  to  remains.  This 
memory  is  not  available  to  users  due  to  the  restrictions  on  downloading  capability  (see  page  78, 
'Downloadable  Software").  The  630  process  is  a  trusted  process  and  is  part  of  the  TCB  (see  page 
?4,  'TCB  Boundary"). 

When  the  630  MTG  is  powered  on  or  reset,  the  "cntlproc"  thread  is  started.  This  L  the  underlying 
r-  -ad  which  reads  all  mouse  input  and  controls  the  creation  and  deletion  of  window  threads.  A 
thread  is  created  for  each  window  created  on  the  terminal.  These  threads  are  called  "wproc" 
threads.  This  creation  involves  allocating  a  process  structure  and  private  stack  for  that  thread,  and 
initialising  the  keyboard  queue  (input  from  keyboard)  and  receive  queue  (input  from  host).  When  a 
window  is  deleted  (via  mouse  option),  the  thread  for  that  window  is  deleted.  This  involves  clearing 
queues,  freeing  the  stack  and  unlinking  the  process  structure  from  the  circular  queue,  thus  freeing  it. 
This  circular  queue  is  used  for  scheduling  threads  for  execution.  Each  window  is  securely  labeled. 
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This  is  described  on  page  74,  'Window  Labels'. 

2.4.4.2  Logging  Into  The  Host 

A  user  invokes  the  trusted  path  on  the  630  MTG  terminal  by  powering  the  terminal  down  and  back 
up,  or  by  pressing  the  shift,  Ctrl,  and  Esc  keys  simultaneously.  When  this  is  done,  a  new  getty  is 
created  and  is  attached  to  that  terminal’s  port.  Then  getty  sanitizes  the  tty  line  and  any  xt  devices 
previously  associated  with  the  terminal,  and  ensures  that  all  processes  attached  to  that  terminal 
port  are  killed  via  the  kill  system  call  with  the  argument  '-9',  which  specifies  a  nonmaskable 
termination  signal.  Then  getty  reads  the  login  name  and  overlays  itself  with  the  login  program. 
Login  gets  and  veriOes  the  password,  sets  up  the  environment  and  checks  the  device  clearances 
database  (the  /mls/cleardevTUe)  for  security  ranges,  terminal  types  and  the  name  of  the  handler  for 
this  terminal  type.  If  login  doesn’t  find  a  handler  specified  it  overlays  itself  with  the  user’s  shell. 
Login  believes  that  there  is  a  630  MTG  on  the  tty  line  if  it  sees  a  handler  specified  in  the  device 
clearances  entry.  For  example,  the  following  two  entries  in  the  /mls/cleardev  file  show  three 
devices; 

515:4,l,2;l:L;630,/usr/bin/630init; 

516:3;0;L:4425; 

517:5,1,2:1  ;L;630,/ usr/bin /630init  -a: 

In  this  example,  the  device  with  a  device  number  of  515  has  a  maximum  clearance  of  level  4  with 
categories  1  and  2;  has  a  minimum  clearance  of  level  1;  is  a  login  device  hardwired  to  a  630  MTG 
terminal;  and  executes  /usr/hin/6S0init  in  place  of  the  usual  login  shell.  The  next  device,  also  a 
login  device,  has  maximum  clearance  of  level  3  and  minimum  clearance  of  level  0  (SYSTEM);  is 
hardwired  to  a  4425  terminal;  and  runs  the  usual  login  shell.  For  a  630  MTG,  login  should  Hnd 
/ usr/ bin/ 6S0init  specified  as  the  handler.  The  final  device  shown  here  with  a  device  number  of  517 
has  a  maximum  clearance  of  level  5  with  categories  1  and  2;  has  a  minimum  clearance  of  level  1;  is  a 
login  device  (i.e.,  a  device  on  which  a  getty  can  be  spawned)  hardwired  to  a  630  MTG  terminal; 
executes  /utr/ bin/ dSOinit  in  place  of  the  usual  login  shell;  and  will  transmit  to  the  audit  trail  all 
data  that  is  declassified  on  the  630  MTG  terminal. 

2.4.4.3  Logging  Into  the  Second  Host 

The  trusted  path  on  the  second  host  is  invoked  by  dropping  the  DTR  (Data  Terminal  Ready)  signal 
which  can  be  accomplished  by  exiting  the  second  host  connection  via  the  mouse  menu.  The  process 
then  continues  as  described  above. 

2.4.4.4  The  630init  Process 

SSOinit  is  a  transient  process  which  is  overlayed  by  layers  (as  explained  below).  This  program  first 
verifies  that  the  terminal  is  indeed  a  630  MTG  with  the  correct  firmware  version  (version  8;8;6). 
Next  6S0init  checks  to  see  if  the  firmware  has  a  recognized  checksum.  If  the  firmware  responds  to 
the  checksum  inquiry  with  a  valid  checksum,  dSOinit  concludes  that  the  user  has  already 
downloaded  the  System  V/MLS  firmware  modifications  and  overlays  itself  with  layers  immediately. 
This  is  the  case  when  the  SSOinxt  process  is  invoked  on  a  second  host  connection. 

Otherwise,  dSOxnit  downloads  the  chk6S0  program,  which  verifies  the  state  of  the  terminal,  and 
computes  a  vector  table  checksum  and  a  ROM  checksum  (checking  for  an  un-corrupted  terminal 
ROM).  Chk6S0  reports  the  terminal  state  and  computed  checksums  to  SSOinit  and  returns  the 
address  of  the  end  of  ROM  as  an  extra  check  to  make  sure  that  the  Hrmware  modifications  are 
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downloaded  to  the  correct  place.  Finally  chkSSO  determines  that  no  printer  is  enabled  and  that  the 
cartridge  port  is  not  in  use. 

If  these  checks  succeed,  the  fw.mods  executable  flle  is  downloaded  (by  SSOinit)  and  run  on  the  630 
MTG  terminal,  fw.mods  writes  the  security  enhanced  routines  into  RAM  and  sprinkles 
modiHcations  throughout  the  RAM  vector  table  so  that  the  terminal  will  support  the  System 
V /MLS  security  policy;  in  doing  so,  it  creates  a  secure  smart  terminal  environment.  The  two  main 
parts  of  this  firmware  modification  involve: 

1.  Copy  the  firmware  vector  table  from  ROM  into  RAM.  All  functions  called  by  the  firmware 
will  be  branched  to  via  this  RAM  table,  fw.mods  modifies  addresses  in  the  vector  table  to 
branch  to  multi-level  handling  routines  for  the  630  MTG  terminal.  This  ensures  use  of  the 
trusted  630  functions. 

2.  Changes  the  pointers  for  the  PPkeys  which  ^e  located  in  630  MTG  Non-Volatile  RAM 
(NVRAM)  storage,  causing  them  to  be  made  inaccessible;  these  NVRAM-located  items  are 
effectively  nulled  each  time  the  terminal’s  trusted  path  is  invoked.  Pointers  to  setup 
information,  also  kept  in  NVRAM,  are  not  changed^. 

Finally,  dSOxnit  overlays  itself  with  layers. 

2.4.4.5  Layers 

Layers  seta  up  the  xtO  control  connection  and  the  xtl  user  window,  and  labels  the  xtl  window  with 
the  security  label  of  that  device’s  minimum  label,  or  of  the  user’s  requested  label  (default=minimum 
label),  whichever  is  higher.  The  label  on  this  window  (along  with  the  user’s  current  operating  label) 
may  be  changed  (through  execution  of  trusted  code)  by  the  newpriv  command  (see  page  51, 
"Changing  Subject  Sensitivity  Label  Information"). 

Layers  causes  the  630  MTG  to  operate  in  layers  mode  and  arranges  to  pass  SIGHUP  to  all  its 
descendants.  It  makes  the  real  tty  device  private  to  the  TCB.  Layers  reads  its  commands  from 
channel  0  and  creates/deletes  windows  until  receiving  the  exit  command.  Layers  creates  new 
processes,  overlays  them  with  a  shell  and  terminates  those  processes  running  in  windows  to  be 
deleted.  Since  layers  is  invoked  directly  from  login,  channel  0  can  be  trusted  as  a  path  for 
communication  between  the  terminal  and  the  host.  Channel  0  in  each  set  of  xt  devices  will  be 
private  to  the  TCB.  Users  cannot  invoke  layers  directly  and  layers  is  not  a  setuid  to  root  program. 

From  this  point  forward,  the  user  operates  under  layers,  and  may  create  and  delete  up  to  six  more 
host  windows,  simply  by  selecting  the  New  option  with  the  mouse.  After  selecting  the  New  option,  a 
submenu  is  presented  for  each  host.  After  selecting  the  appropriate  host  another  submenu  is 
presented.  This  submenu  is  a  list  of  privileges  that  the  user  is  authorised  to  operate  in.  This 
privilege  submenu  was  created  by  layers  as  a  convience  to  the  user.  This  menu  is  static  and  is  based 
on  information  obtained  at  login  time.  Selecting  a  privilege  from  this  menu  will  cause  a  window  to 
be  created  at  that  privilege.  This  is  accomplished  by  invoking  the  newpriv  command,  rather  than 
running  the  user’s  default  login  shell.  If  the  user  does  not  select  a  privilege  from  the  menu  but 
simply  selects  the  host,  the  window  is  labeled  with  the  user’s  login  security  label  and  the  user’s 


9.  This  w  accpptable  breause  terminal  rbarsctpriatira  such  as  screen  color  anil  keyboard  repeat  rate  are  not  security 
relevant.  Terminal  setup  options  can  only  be  modified  by  predefined  mouse  operations. 
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default  login  shell  is  run  in  that  window. 

2.4.4.6  wproc 

Wproc  is  the  terminal  emulator  for  windows  in  the  layers  environment.  Once  a  window  is  created, 
host  UNIX  processes  can  be  run  in  that  window  (e.g.,  shell).  This  section  discusses  how  it  is  started 
and  what  content  is  stored  in  its  associated  structures. 

The  cntlproe  thread  is  the  underlying  thread  on  the  630  MTG;  it  is  always  running  (begins 
execution  when  machine  is  powered  up).  Cntlproe  initializes  the  ’Show  Label’  menu  entry  and  then 
loops  forever  waiting  for  mouse  clicks  and  setting  flags. 

When  a  new  window  is  requested,  cntlproe  creates  the  wproc  thread  which  then  begins  execution. 
Creation  of  this  (or  any)  thread  involves  a  number  of  activities;  allocating  a  process  structure, 
allocating  a  stack  for  wproc,  setting  the  thread’s  state  to  RUN,  initializing  keyboard  (buffers  data 
ffom  keyboard)  and  receive  (buffers  data  from  host)  queues  (used  in  the  xt  protocol),  initializing 
registers  to  0  and  specifying  the  wproc  program  to  run  in  the  thread.  Each  wproc  thread  is 
2tssociated  with  a  window  via  specification  in  the  process  structure. 

When  wproc  begins  execution,  it  initializes  its  window  structure  and  draws  the  label  bar  on  the 
window.  Then  it  enters  an  infinite  loop  checking  flags  set  by  cntlproe.  These  various  flags  result  in 
the  processing  of  mouse  actions,  label  changes,  window  moves  and  reshapes,  window 
activation /deactivation,  cut  and  paste,  and  keyboard  input,  wproc  constantly  polls  for  these  events, 
each  event  having  its  own  service  routine. 

The  window  structure  contains  fields  for  cursor  position,  window  size  and  boundaries,  length  of  label 
string,  etc.  The  wproc_line  structure  is  the  structure  allocated  for  each  line  of  text  on  the  window, 
and  contains  the  text,  its  size  and  pointers  to  the  line  which  precedes  it  and  the  line  which  follows  it. 
Other  structures  wproc  uses  are  structures  for  specifying  window  coordinates  and  rectangles.  These 
variables  are  manipulated  on  the  wproc  stack. 

The  wproc  thread  is  labeled  (much  like  a  MLS  host  process  has  a  label)  in  the  process  structure. 
Whenever  a  label  is  sent  from  the  host  to  the  630  MTG  terminal  (e.g.,  at  login  when  the  first 
window  is  labeled,  at  each  newpriv  after  that),  the  label  is  stored  in  the  630  MTG  memory.  Each 
wproc  process  structure  contains  pointers  to  the  location  in  630  MTG  memory  where  the  actual 
label  is  store  in  canonical  and  human-readable  form. 

2.4.4.7  Window  Labels 

Each  window  has  a  trusted,  human-readable  label.  This  label  is  set  to  be  that  of  the  host  process 
operating  "in"  the  window.  The  top  line  of  the  window  is  known  as  the  label  bar,  which  is  where  the 
human-readable  label  is  displayed.  Writing  by  user  processes  in  the  label  bar  is  disabled  by  the 
firmware.  This  is  accomplished  in  wproc,  which  is  hardcoded  to  ignore  the  escape  sequence  the  host 
sends  to  write  into  the  label  bar.  Ako,  since  the  window’s  label  k  stored  in  the  process  structure  and 
not  in  the  window  buffer  itself,  a  user  cannot  move  the  mouse  into  the  label  bar  area  and  click  into 
it. 

To  untrusted  software  running  on  the  host  system,  each  window  (xtl-xtn)  appears  to  be  a  dktinct 
terminal.  Up  to  seven  windows  may  be  active  at  any  given  time  (deleted  windows  may  be 
recreated),  at  any  classification  level  for  which  the  user  and  the  terminal  device  are  authorized.  It  k 
possible  for  the  complete  security  label  of  a  window  to  be  larger  than  the  space  available  in  the 
header  line.  In  that  event,  as  much  of  the  security  label  as  possible  k  dkplayed  (the  hierarchical 
classification  k  always  dkplayed),  and  an  indicator  provided  that  the  label  k  longer  than  k  shown'*’. 


Revkion  10.4 


-  74- 

overview.mm 


(Revked  5/24/91) 


Final  Evaluation  Report  klkl  System  VAiLS 

System  Overview 


Clicking  a  mouse  button  on  the  appropriate  pop-up  menu  box  will  display  the  entire  security  label 
of  such  a  window. 

Window  labels  may  change  (via  trusted  code),  but  they  do  not  "float,'  In  the  event  that  a  user 
executes  the  newpriv  or  exit  command  to  change  authorizations,  the  label  of  the  window  in  which 
the  user  is  operating  wiU  reflect  the  change.  No  other  window  will  be  affected. 

Host  windows  are  labeled  in  response  to  an  ioctl  from  the  host.  All  label  information  is  sent  over  the 
xtO  control  connection  exclusively.  The  MLSLBLCHG  ioctl  takes  as  arguments  lengths  and  pointers 
to  the  canonical  and  human-readable  forms  of  the  label  being  sent.  The  program  invoking  the  ioctl 
sends  it  to  the  virtual  channel  on  which  that  program  is  running.  The  xt  driver  re-routes  the 
information  to  the  control  channel  (xtO)  in  a  message  that  contains  the  virtual  xt  number  and  the 
actual  label  (in  canonical  and  human-readable  form).  The  xt  driver  will  not  allow  the  ioctl  unless  it 
is  sent  from  a  process  running  as  root.  Demux  receives  this  control  information  and  pcisses  the 
received  packets  to  the  doctl  routine.  Docti  reconstructs  the  message  from  the  packets,  postpends  a 
"host  category  bit'  to  the  canonical  form,  stores  the  label  in  both  forms  in  630  MTG  memory,  and 
sends  pointers  thread,  which  saves  the  pointers  in  its  process  structure  and  displays  the  human- 
readable  string  in  the  label  bar.  If  the  new  label  does  not  dominate  the  old  label,  secuiity  relevant 
data  is  cleared;  pointers  to  the  old  label  are  replaced  with  pointers  to  the  new  label  and  the  data 
currently  in  the  window  (and  its  scrolling  buffer)  is  cleared. 

In  the  event  of  a  very  long  label,  if  there  is  not  enough  memory  in  which  to  store  that  label  then  the 
630  MTG  will  either  refuse  to  create  the  requested  window,  or  will  delete  the  window. 

2.4.4.8  Seciu-e  Labeling  at  Login/Window  Creation 

During  the  login  sequence  layers  sets  up  channel  0,  the  control  channel  as  a  private  communication 
channel  between  the  host  and  the  terminal.  After  establishment  of  this  communication  channel 
layers  determines,  using  Ispriv,  the  permissible  privilege  set  for  this  session,  based  on  the  user’s  and 
the  terminal’s  clearances.  The  names  of  these  privileges  are  sent  to  the  terminal  on  channel  0. 
Cntlproc  generates  the  privilege  submenu  under  the  'New/Host'  menu  selection.  The  privilege  list 
is  stored  in  the  same  order  in  both  layers  and  cntlproc  so  that  when  a  privilege  is  selected  from  the 
privilege  menu  only  its  index  needs  to  be  sent  to  the  host.  Also  established  at  this  time  is  an 
'Authorization  to  Declassify'  bit.  This  bit  is  stored  in  the  630  process  structure  and  is  set  based  on 
the  contents  of  the  the  information  passed  by  layers  to  cntlproc.  If  the  user  is  a  member  of  the 
group  secadm  or  the  password  field  associated  with  the  group  secadm  contains  the  keyword 
'<ANY>'  then  layers  notifies  cntlproc  that  the  user  is  authorized  to  declassify  information  on  the 
630  MTG  terminal**. 

Next,  layers  initialises  the  first  window.  Before  starting  the  shell  which  is  to  run  in  that  window,  it 
calls  the  mis  library  routine  devassign  to  set  the  security  label  of  the  xt  device.  When  devassign  sets 
the  label  associated  with  the  xt  device,  it  issues  the  MLSLBLCHG  ioctl  to  inform  the  630  MTG  of 
the  new  label. 


in.  The  aJniinistrator  is  instriirtnl  in  th(*  TFM  to  choosr  hiprarchirai  Ips’pI  names  to  be  no  lonRpr  than  20  rharartors. 

11.  This  information  is  established  during  the  login  initialization  and  remains  static  throughout  the  login  session.  This 
requires  that  a  user  log  off  the  system  before  the  authorization  can  be  revoked. 
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When  a  new  window  is  requested  via  a  mouse  click,  the  underlying  entlproc  thread  reads  the  mouse 
click  £Uid  sends  a  command  to  layers  to  create  a  window  at  a  specified  privilege.  Layers  either 
invokes  the  trusted  process  newpriv  to  run  in  the  newly  created  window  or  if  the  user  requested  a 
new  window  with  his/her  login  privilege  invokes  the  process  specified  by  the  user’s  SHELL 
environment  variable  after  initializing  the  xt  device  by  using  devassign. 

2.4.4.9  Secure  Labeling  at  Newpriv /Ebdt 

The  newpriv  and  exit  (or  <CNTL-D>)  commands  call  devassign.  When  devassign  changes  the  label 
associated  with  the  xt  device,  it  issues  the  MLSLBLCHG  iocti  to  inform  the  630  MTG  of  the  new 
label.  The  terminal  then  proceeds  as  before. 

2.4.4.10  Window  Creation 

The  enforcement  mechanism  used  to  ensure  the  integrity  of  windows  and  their  associated  buffers  is 
based  primarily  upon  the  memory  management  scheme  implemented  by  the  630  MTG  terminal. 
Memory  within  a  630  MTG  terminal  is  allocated  via  two  calls:  alloc  and  gcalloc,  as  described  on 
page  20,  *630  MTG  Memory  Mangement'  These  calls  are  used  by  the  terminal  and  can  not  be  used 
by  user  programs,  since  downloading  is  restricted  (see  page  78,  ’Downloadable  Software*).  Each 
window  buffer  is  composed  of  memory  allocated  by  gcalloc.  Buffers  have  a  maximum  size  of  lOK 
bytes;  this  is  an  arbitrary  limit  imposed  by  the  630  MTG  firmware.  When  a  user  creates  a  buffer, 
the  terminal  ensures  that  there  are  lOK  bytes  of  memory  space  available.  If  not,  the  gcalloc  memory 
pool  is  compacted.  If  there  is  still  not  a  large  enough  memory  fragment,  an  ’out  of  memory*  error  is 
returned  and  the  window  creation  fails  (but  terminal  operations  may  continue). 

Once  the  terminal  ascertains  that  sufficient  memory  exists  for  a  new  window  to  be  created,  layers 
sends  the  label  of  the  connection  over  channel  0.  Cntiproc  creates  a  process  structure  for  a  new 
wproc  thread.  The  wproc  program  (executing  in  the  ruproc  thread)  allocates  for  itself  a  window 
structure  (on  its  stack)  and  allocates  one  zero-length  data  line.  This  window  structure  contains  local 
variables  (e.g.,  window  coordinates)  and  contmns  no  user  data.  After  setting  up  the  window 
structure,  wproc  enters  an  infinite  loop  checking  the  label-change  flag  at  the  top  of  the  loop.  When 
the  set  flag  is  detected,  wproc  clears  the  existing  label  on  the  window,  if  any,  and  copies  the  new 
label  into  the  window  structure  and  displays  it.  The  details  of  this  procedure  are  described  on  page 
74,  ’Window  Labels’.  As  the  first  line  is  added  into  the  buffer,  the  length  of  the  first  data  line 
increases.  Each  new  line  which  appears  on  the  terminal  is  allocated  another  line  of  memory  from  the 
terminal  pool  of  free  memory,  and  the  lines  are  linked  together  to  form  a  doubly-linked  list  of  text 
throughout  the  terminal’s  memory.  Since  each  line  in  each  buffer  may  be  traced  back  to  its  header, 
all  data  is  still  associated  with  its  sensitivity  label.  When  the  window  buffer  fills,  lines  stored  at  the 
beginning  of  the  buffer  are  deleted  as  new  lines  are  created. 

2.4.4.11  Local  Windows 

In  the  event  that  a  user  wishes  to  create  and  modify  a  buffer  without  use  of  the  host  machine,  the 
630  MTG  terminal  allows  for  ’local  windows*  -  windows  which  have  no  process  on  the  host 
associated  with  them.  Although  there  is  no  host  process  executing  in  a  local  window,  each  local 
window  still  has  an  active  wproc  thread  executing  and  has  a  process  structure  associated  with  it. 

Local  windows  may  be  created  before  a  user  logs  on  to  the  host;  however,  these  will  be  erased  after 
the  trusted  path  to  login  has  been  invoked.  Local  windows  may  also  be  created  during  a  terminal 
session  by  copying  the  complete  contents  from  a  host-connected  window  (it  is  'peeled’).  Such  a 
window  will  have  the  security  label  of  the  window  from  which  the  information  originated.  Security 
labels  on  local  windows  cannot  be  changed.  Local  windows  use  mouse-based  editing.  Off-screen 
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buffering  is  employed  in  both  host  and  local  windows. 

2.4.4.12  Cat  and  Paste 

The  630  MTG  terminal  associates  a  buffer  with  each  window,  which  is  effectively  a  system  buffer 
which  is  labeled  with  the  label  of  the  associated  window.  The  user  can  scroll  through  these  buffers 
and  'cut  and  paste*  text  from  one  window  to  another.  This  functionality  operates  in  accordance 
with  the  System  V/MLS  security  policy.  The  cut  and  paste  operation  in  a  window  is  not  an  atomic 
action.  First  the  user  highlights  (via  mouse  manipulation)  text  to  be  moved,  then  presses  a  mouse 
button.  Each  cut  or  copy  will  transfer  the  text  to  a  newly  allocated  (via  alloc)  Global  Save  Buffer 
(GSB),  which  is  effectively  a  buffer  without  a  window  attached,  bearing  the  label  of  the  window 
from  whence  the  cut  or  copied  text  originated.  The  label  of  the  GSB  is  stored  in  the  actual  buffer, 
unlike  window  buffers  which  have  their  labels  stored  in  process  structures.  In  this  operation,  the 
wproc  thread  associated  with  the  source  window  is  reading  text  itself  and  writing  it  into  the  GSB. 
The  user  must  then  move  to  and  activate  the  target  window,  move  the  mouse  to  the  location  where 
the  text  is  to  be  inserted,  and  press  a  mouse  button.  Here  the  wproc  thread  associated  with  the 
target  window  is  reading  text  from  the  GSB  (possibly  at  a  lower  level)  and  writing  it  into  the  target 
window’s  buffer.  The  target  window’s  buffer  has  the  same  security  label  as  the  wproc  thread  causing 
the  action.  The  630  MTG  terminal  will  compare,  via  a  simple  compare  operation  on  the  canonical 
form  of  the  labels  involved,  the  sensitivity  of  the  GSB  with  the  sensitivity  of  the  target  window.  If 
the  target  does  not  dominate'^  the  GSB  then  wproc  will  check  the  'Authorised  to  Declassify'  bit^^ 
and  if  the  user  is  allowed  to  declassify  information  a  pop-up  window  containing  the  following  text  is 
displayed: 

declassify  from 
<LABEL1> 

to 

<LABEL2> 

7 

Button  1  =  Yes;  other  buttons  =  No 

After  interactive  confirmation  has  been  received  the  contents  of  the  global  save  buffer  wiU  be 
pasted/sent  to  the  target.  If  the  transfer  is  allowed,  the  terminal  copies  the  text  from  the  GSB  to 
the  target  window.  This  may  take  place  between  any  two  windows,  including  local  windows 
(described  above). 

Whether  a  declassification  attempt  on  the  630  terminal  succeeds  or  fails  a  message  is  sent  to  layers 
over  the  trusted  channel  0.  This  message  includes  an  indication  of  whether  the  requested  operation 
was  granted  or  denied,  what  the  source  and  target  windows  were,  the  labels  involved  and  if  the 
'verbose  auditing'  bit  has  been  set,  the  full  text  of  the  transferred  data.  Layers  collects  this 
information  into  a  ULI  record,  which  it  writes  to  /dev/sat/trOOl. 


12.  The  only  Inhel  comparision  is  for  dominnnce,  if  the  two  labels  are  non-comparable,  the  transfer  is  considered  as  a 
declassification. 

13.  This  bit  is  initialized  by  (a|rers|lS)  dnring  the  login  procedure. 
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2.4.4.13  Programmable  Function  Keys 

On  the  base  630  MTG  terminal,  the  character  strings  associated  with  the  user  programmable 
function  keys  (PFkeys)  are  stored  in  NVRAM.  In  the  security  enhanced  630  MTG  terminal,  a  new 
PFkey  storage  area  is  allocated  in  RAM  during  login.  There  are  two  program  function  key  areas 
allocated,  one  per  host.  The  result  is  that  the  contents  of  PFkeys  will  not  be  retained  between  login 
sessions  (on  either  host). 

The  PFkeys  may  be  programmed  either  via  sending  escape  sequences  to  the  630  MTG  terminal  or 
use  of  the  PFkey  edit  menu.  A  program  that  sends  an  escape  sequence  to  the  630  MTG  to  program 
a  function  key  will  write  in  the  program  function  key  area  associated  with  the  host  from  which  the 
program  is  executing.  In  addition,  the  label  of  the  process  sending  the  escape  sequences  must  be 
equal  to  the  label  of  the  PFkey  edit  menu.  The  program  function  key  edit  menu  has  been  split,  so 
that  the  user  may  request  either  host  I’s  area  to  be  displayed,  or  host  2’s.  These  menus  are  labeled 
with  the  user  login  privilege  and  with  the  appropriate  host  category  bit.  This  is  required  to  preclude 
cross-host  cut-and-paste  using  the  PFKey  edit  menus. 

A  user  hitting  a  program  function  key  will  cause  the  630  MTG  keyboard  driver  to  look  up  the 
program  function  key  area  associated  with  the  current  window’s  host.  Thus,  information  read  from 
and  written  to  the  program  function  key  area  is  separated  by  host. 

2.4.4.14  Downloadable  Software 

The  downloading  of  software  can  only  be  initiated  by  the  trusted  process  dmdid.  Dmdld  checks  that 
the  terminal  is  in  layers  mode  and  changes  ownership  of  the  tty  to  root  read/write  only.  It  notifies 
the  terminal  (actually  the  channel  associated  with  the  window  in  which  the  download  was  invoked) 
to  expect  a  download,  using  the  JBOOT  ioctl  (which  is  restricted  to  root  use  only).  Finally  it  does 
the  actual  download  (sends  the  program  on  the  smne  channel)  using  the  xt  protocol.  When  the 
download  is  complete,  dmdld  changes  ownership  of  the  tty  back  to  user  with  previous  access  mode, 
and  execution  resumes  with  the  downloaded  program. 

Downloading  software  is  restricted  as  follows.  Dmdld  (setuid  to  root)  only  downloads  programs  from 
the  duectory  /usr/dmd/bin,  which  is  writable  only  by  root.  The  TFM  prohibits  the  system 
administrator  from  changing  the  contents  of  this  directory.  The  system  no  longer  conforms  to  the 
evaluated  configuration  if  the  system  administrator  adds  anything  into  this  directory.  Since  users 
can  not  write  to  this  directory,  they  can  not  write  their  own  downloadable  programs. 

2.4.4.15  Additional  Subjects  and  Objects  Introduced 

The  630  MTG  terminal  supports  one  entity  which  can  be  recognised  as  a  trusted  subject.  This 
entity  is  a  multiple-thread  process.  It  enforces  the  system  security  policy  on  the  630  MTG  terminal. 

There  is  only  one  type  of  storage  object  local  to  the  630  MTG  terminal:  the  buffers  in  which  the 
GSB,  individual  tenninal  sessions  and  locd  windows  exist.  These  buffers  are  system  objects 
manipulated  by  the  630  MTG  and  are  storage  objects,  in  that  they  contain  data  which  is  subject  to 
the  Mandatory  Access  Control  and  Object  Reuse  requirements.  They  are  not  sharable  with  any 
other  user  on  the  system,  and  are  destroyed  when  the  user  ends  the  tenninal  session.  These  window 
buffers  are  not  directly  accessible  by  untrusted  subjects. 

2.4.4.16  Auditing  on  the  630  MTG 

Two  security  relevant  events  can  occur  locally  within  the  630  MTG  terminal.  These  events  are: 
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1.  declassiHcation  of  data  within  the  630  MTG,  and 

2.  unsuccessful  paste/send  operation  due  to  policy  violation. 

The  630  MTG  terminal,  upon  detection  of  one  of  these  events,  contructs  an  audit  record  which 
contains  all  pertinent  data  and  conununicates  this  to  layers.  Layers  upon  receiving  thb  information 
opens  a  ULI  channel  and  transmits  the  audit  record  to  the  audit  trail.  Some  events  within  the  630 
MTG  terminal,  are  considered  sufficiently  audited  by  inference.  For  exaunple,  window  buffer 
creation  is  implicitly  audited  in  that  the  devassign  of  the  associated  xt  channel  implies  the  creation 
of  the  window  buffer.  Actions  audited  by  the  host  can  be  distinguished  in  the  audit  trail  as  having 
taken  place  in  a  specific  window.  This  information  is  derived  from  the  device  and  inode  number 
which  are  stored  in  the  audit  trad.  When  the  audit  trail  is  examined  in  verbose  mode  (see  page  92, 
'Audit")  the  'window  name'  (i.e.,  xt3)  is  printed.  Similarly  when  two  (or  more)  processes  are 
created  in  different  windows  on  a  630  terminal,  their  creation  and  the  opening  of  System  V/MLS 
objects  are  auditable.  Therefore  any  process  associated  with  a  630  MTG  terminal  must  be  presumed 
(by  the  administrator)  to  be  able  to  exchange  data  with  any  other  process  associated  with  the 
terminal,  as  long  as  the  communication  does  not  violate  the  system  security  policy. 

2.4.4.17  Logging  Out  of  a  630  MTG  teiminal 

The  terminal  can  detect  drop  of  DTR  (Data  Terminal  Ready)  signal  at  any  time  during  terminal 
session. 

In  order  to  end  a  630  MTG  terminal  session,  the  user  may  take  one  of  three  distinct  actions:  power 
cycle  the  terminal;  hold  the  shift,  control,  and  escape  keys  simultaneously  (this  performs  a  software 
power-cycle);  or  select  the  EXIT  option  with  the  mouse.  The  first  two  actions  will  cause  DTR  to 
drop;  the  host  will  detect  this,  and  send  the  hangup  signal  to  all  processes  on  the  host  that  are 
affiliated  with  that  terminal.  If  a  process  chooses  to  catch  or  ignore  the  SIGHUP  and  has  not 
disconnected  itself  from  the  terminal  device,  it  will  be  killed  by  c/e  fry  when  the  next  user  attempts  to 
log  in  on  the  terminal  device.  When  power  is  cycled,  RAM  is  cleared.  The  reset  key  combination 
causes  the  terminal  to  initiate  the  clear /selftest/reboot  sequence.  The  use  of  the  EXIT  option  will 
send  an  instruction  to  the  layers  program  running  on  the  host  which  instructs  it  to  terminate  the 
session.  When  cntlproc  gets  the  mouse  click  for  EXIT,  it  sends  a  message  to  the  layers  program 
running  on  the  appropriate  host.  Layers  then  kills  all  shells  running  in  all  windows  and  sends  a 
message  back  to  the  terminal.  On  receiving  the  return  message  from  layers,  doctl  runs  the 
unbootmux  routine.  The  unbootmux  routine  checks  to  see  if  this  closes  the  last  active  host 
communication  channel.  If  this  is  the  last  host  connection,  unbootmux  writes  seros  throughout  all 
of  RAM  and  then  performs  a  self  test.  Otherwise,  it  selectively  clears  all  objects  associated  with  the 
closing  host.  When  layers  dies,  login,  waiting  for  the  death  of  child  signal,  dies  too,  and  a  new  getty 
is  invoked  for  that  line.  This  wUl  log  the  user  off  of  the  host  computer.  After  terminating  all  its 
descendants,  layers  restores  the  real  tty  to  a  known  state  (used  by  getty).  Note  that  the  second  host 
connection  should  only  be  terminated  by  use  of  the  EXIT  option  with  the  mouse.  While  the 
terminal  will  function  properly  if  the  other  methods  described  above  are  used,  they  wUl  terminate 
both  host  connections. 

Based  upon  this  overview  of  the  functionality  of  the  630  MTG  terminal,  it  is  evident  that  there  are 
a  number  of  unique  security  issues  related  to  this  configuration.  More  detaU  on  the  features  and 
assurances  supported  by  the  630  MTG  terminal  wUl  be  found  in  Section  3  of  this  report. 
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2.4.5  Configiiratioii  Management 

The  system,  in  order  to  retain  the  B1  TGSEC  rating,  participates  in  the  Ratings  Maintenance  Phase 
(RAMP).  This  involves  identifying  all  hardware  components  and  tracking  all  software  changes. 
There  is  a  configuration  management  plan  in  place  to  track  changes  made  to  documentation,  source 
code,  test  documentation,  and  test  code.  The  System  V/MLS  RMPlan  document  explains  the 
configuration  management  procedures. 

The  principal  divisions  of  AT&T  which  will  play  a  part  in  muntaining  the  system  are  the 
Technologies  Federal  System  Division  and  AT&T  Bell  Laboratories.  This  section  will  explain  the 
scheme  in  place  for  managing  changes  to  the  System  V/MLS  product,  and  will  then  go  on  to  expl^tin 
how  changes  to  the  underlying  UNIX  System  V  are  tracked. 

The  process  for  managing  changes  made  to  the  System  V/MLS  product  is  as  follows.  All  changes 
are  initiated  through  the  creation  of  a  Modification  Request  (MR).  MRs  are  submitted  to  the 
Configuration  Control  Board  (CCB)  in  order  to  assign  the  MR  to  the  most  appropriate 
individual(s).  These  individuals  are  then  responsible  for  developing  a  solution  for  the  request  as  well 
as  providing  support  and  design  documentation.  After  this  step  the  MR  solution  is  submitted  for 
approval  by  the  CCB.  If  the  solution  is  inadequate,  the  MR  is  rejected  and  the  problems  with  the 
proposed  solution  are  identified.  The  MR  continues  to  be  submitted  with  new  proposals  until  the 
CCB  approves  the  proposed  solution.  All  MRs  are  subject  to  a  test  analysis,  which  determines 
whether  an  appropriate  test  exists,  whether  an  existing  test  must  be  modified,  whether  a  new  test 
must  be  written,  or  if  code  inspection  is  needed. 

Configuration  tools  used  throughout  the  configuration  management  system  aid  in  automating 
procedures.  Currently  the  tools  used  are  Source  Code  Control  System  (SCCS),  SABLE,  and  System 
V/MLS  Tools. 

SCCS  records  all  enhancements  and  changes  made  to  source  code  and  documentation,  comments  on 
each  version,  and  maintains  a  history  of  the  changes  made. 

SABLE  assists  in  the  management  of  product  development  by  performing  modification  request 
tracking,  report  and  query  functions,  and  human  factors  engineering.  Modification  request  tracking 
is  the  mechanism  used  to  track  the  current  status  of  any  MR.  MRs  can  be  in  one  of  a  number  of 
states  (i.e.,  accepted,  under-study,  deferred,  approved,  assigned,  closed).  A  history  is  maintained  of 
all  MRs  through  all  their  states.  Report  and  query  functions  allow  the  user  to  pull  data  base 
records  (specific  or  in  report  format).  Human  factors  engineering  allows  for  a  'customisation”  of 
SABLE  users.  This  customisation  involves  the  setting  of  various  defaults  (e.g.,  preferred  editor, 
menu  vs  commmid  line  entry). 

There  is  manual  interaction  in  place  between  SABLE  and  SCCS.  These  procedures  are  described  in 
the  Rating  Maintenance  Plan  for  System  V/MLS  (RMPlan). 

System  V/MLS  Tools  are  tools  specifically  developed  for  conHguration  management  which  handle 
the  tree  structure  of  the  System  V/MLS  product.  These  tools  are  documented  in  the  RMPlan. 

UNIX  System  V  is  configuration  managed  under  the  SCCS  system  at  Bell  Laboratories,  although 
the  System  V/MLS  VS  As  are  not  participants  in  this  particular  configuration  management  process. 
For  every  RAMP  cycle  that  entails  a  new  release  of  the  base  operating  system  (UNIX  System  V),  an 
analysis  will  be  done  by  the  VSA  for  each  changed  source  file.  All  sources  for  the  releases  of  UNIX 
System  V  to  be  RAMPed  are  maintained  on  a  dedicated  filesystem  by  the  System  V/MLS  VSA. 
The  VSA  will  use  these  sources  for  analysis  of  all  changes.  The  VSA’s  analysis  will  involve  contact 
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with  those  organizations  responsible  for  the  code,  for  various  queries.  The  VSA  sends  the  results  of 
his  or  her  analysis  to  the  CCB.  The  CCB  will  be  responsible  for  approving  the  updates. 

If  a  feature  is  added  to  the  base  operating  system  that  adversely  affects  the  system  security  and 
cannot  be  fixed,  then  the  component  is  removed  when  the  System  V/MLS  product  is  inst^dled  at 
the  customer  site.  If  the  feature  can  be  fixed,  then  the  component  is  added,  if  not  already  present, 
to  the  System  V /MLS  product’s  source  tree  and  work  proceeds  as  normal  for  an  MR. 

The  underlying  hardware  is  not  under  configuration  control  at  the  System  V/MLS  development 
organization,  as  is  the  System  V/MLS  product  (with  histories  of  changes  online,  etc).  The  RAMP 
document**  requires  that  the  hardware  be  configuration  identified  and  analyzed.  The  tracking 
process  works  as  follows:  When  a  new  hardware  base  becomes  available,  the  VSA  examines  the 
design  and  testing  documentation.  In  effect,  he  or  she  does  a  complete  mini-evaluation  on  the 
hardware.  The  VSA  documents  this  analysis,  keeps  it  on  record,  and  presents  the  analysis  to  the 
CCB. 

If  changes  made  to  the  underlying  hardware  are  deemed  potentially  harmful  to  security  by  the  CCB, 
the  CCB  does  not  approve  that  hardware  product  as  an  acceptable  base  and  System  V/MLS  is  not 
ported  to  that  base. 

AT&T  Technologies  Federal  System  Division  is  responsible  for  maintaining  the  rating  for  System 
V/MLS.  The  configuration  management  scheme  enforced  for  System  V/MLS  provides  added 
assurance  that  any  changes  made  to  the  TCB  will  not  compromise  the  trust  of  the  originally 
evaluated  system. 


14.  Rating  Uaintenanee  Phate  Program  Document, 
NCSC.  June  1989. 
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3.  ESvalnation  as  a  Bl  system 

3.1  Discretiofnary  Access  Control 

3.1.1  Requirement 

The  TCB  shall  define  and  control  access  between  named  users  and  named  objects  (e.g.,  files 
and  programs)  in  the  ADP  system.  The  enforcement  mechanism  (e.g.,  self /group/public 
controls,  access  control  lists)  shall  allow  users  to  specify  and  control  sharing  of  those  objects 
by  named  individuals,  or  defined  groups  of  individuals,  or  by  both,  and  shall  provide  controls 
to  limit  propagation  of  access  rights.  The  discretionary  access  control  mechanism  shall, 
either  by  explicit  user  action  or  by  default,  provide  that  objects  are  protected  from 
unauthorized  access.  These  access  controls  shall  be  capable  of  including  or  excluding  access 
to  the  granularity  of  a  single  user.  Access  permission  to  an  object  by  users  not  already 
possessing  access  permission  shall  only  be  assigned  by  authorized  users. 

3.1.2  Applicable  Features 

DAC  is  implemented  in  System  V/MLS  via  protection  bits  on  all  named  objects  enumerated  on 
page  36,  "Objects”.  Protection  bits  are  sufiicient  to  provide  self/group/public  controls  on  sharing  of 
objects  by  named  individuals  and  defined  groups  of  individuals.  System  V/MLS  aJso  allows  for 
user-defmable  groups,  called  'privileges',  which  aid  in  controlling  access  and  realistically  fuIHll  the 
requirement  of  including  or  excluding  access  to  the  granularity  of  a  single  user.  This  is  accomplished 
by  allowing  a  user  to  change  the  privilege  of  a  file  to  a  specific  privilege  which  the  user  may  define, 
and  then  allowing  the  user  to  set  the  access  mode  bits  to  allow  (or  deny)  members  of  the  privilege 
access  to  the  file.  System  V/MLS  provides  a  default  protection  on  newly  created  objects  of  read, 
write,  and  execute  access  for  the  owner  of  that  object  and  no  access  to  adl  others.  For  a  complete 
description  of  DAC  see  page  42,  'Discretionary  Access  Control". 

DAC  and  the  630  MTG  terminal:  In  the  context  of  the  630  MTG  terminal,  DAC  is  a  not  an  issue. 
The  terminal  retains  no  information  between  the  time  one  user  logs  off  of  the  System  V/MLS 
system  and  the  next  user  logs  on;  therefore,  the  only  information  to  which  the  terminal  has  access  at 
any  given  time  is  information  available  to  the  user  currently  logged  into  the  host.  The  terminal  has 
no  role  in  mediation  of  any  discretionary  access,  and  therefore  need  only  ensure  that  the  access 
control  decision  of  the  host  is  not  circumvented.  Since  the  terminal  physically  does  not  have  access 
to  information  to  which  its  user  does  not  have  discretionary  access,  this  requirement  is  trivially 
satisfied. 

3.1.3  Conchislon 

System  V/MLS  satisfies  the  Bl  Discretionary  Access  Control  requirement. 

3.2  Object  Reuse 
3.2.1  Requirement 

All  authorizations  to  the  information  contained  within  a  storage  object  shall  be  revoked  prior 
to  initial  assignment,  allocation,  or  reallocation  to  a  subject  from  the  TCB’s  pool  of  unused 
storage  objects.  No  information,  including  encrypted  representations  of  information, 
produced  by  a  prior  subject’s  actions  is  to  be  available  to  any  subject  that  obtains  access  to 
an  object  that  has  been  released  back  to  the  system. 
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3.2.2  Applicable  Features 

In  System  V/MLS,  the  system  administrator  is  responsible  for  ensuring  that  the  object  reuse 
requirements  on  mountable  media  (i.e.,  tapes  and  diskettes)  are  followed.  The  administrator  must 
reformat  the  media  using  the  appropriate  UNIX  format  commands  explained  in  section  5.6  of  the 
System  V/MLS  Trusted  Facility  Manual. 

The  System  V /MLS  TOB  ensures  the  object  reuse  requirements  are  checked  for  the  following: 
directories 
regular  files 
special  Hies 
named  pipes 
unnamed  pipes 
memory 

shared  memory  segments 
message  queues 
semaphores 

3.2.2.1  File  System  Objects 

The  file  system  objects  are  directories,  regular  Hies,  pipes  and  special  files.  System  V/MLS  allocates 
disk  blocks  in  a  manner  which  ensures  that  no  object  reuse  is  possible  for  each  of  the  previously 
mentioned  file  system  objects  (for  further  information  see  page  61,  'Object  Reuse').  Both  named 
and  unnamed  pipes  use  kernel  buffers  to  store  data.  The  allocation  of  kernel  buffers  disallows  object 
reuse  for  pipes  as  well  as  file  system  objects  (see  page  62,  'Disk  Block  AUocation'). 

3.2.2.2  Memory'Based  Objects 

System  V/MLS  utilises  a  demand  paging  mechanism.  When  a  process  requires  another  page  of 
memory,  the  growreg  kernel  routine  determines  the  number  of  new  pages  to  be  used,  and  initialises 
them  by  marking  them  invalid.  When  the  process  references  the  new  page,  the  system  clears  the 
page.  Shared  memory  segments  are  implemented  using  the  demand  paging  mechanism.  (For 
further  details  see  page  61,  'Object  Reuse'.) 

3.2.2.2.1  Message  Queues  and  Semaphores 

When  memory  for  semaphores  and  message  queues  is  initially  allocated,  System  V/MLS  clears  this 
memory  to  ensure  that  no  previous  data  may  be  obtained.  Hereafter,  both  message  queues  and 
semaphores  are  cleared  upon  deallo>"ation  in  System  V/MLS.  Deallocation  occurs  when  the 
IPC^RMID  command  is  sent  to  the  msgctlor  seme  (/system  call. 

3.2.2.3  Object  Reuse  on  the  630  MTG  Temunal 

In  order  to  prevent  the  scavenging  of  information  from  the  terminal  buffers  when  the  connection  to 
the  host  computer  is  broken,  the  630  MTG  will  sero  all  windows  and  buffers,  including  local 
windows  and  Programmed  Function  (PF)  keys.  For  the  purpose  of  this  evaluation,  the  term 
'storage  object'  may  be  defined  simply  as  either  a  host  or  local  window  buffer  in  the  context  of  the 
630  MTG  terminal.  Each  of  these  buffers  is  appropriately  labeled,  and  each  contains  information 
and  is  subject  to  the  object  reuse  requirement.  Eliminating  object  reuse  on  the  630  MTG  terminal 
is  effectively  a  two-step  process;  first,  when  a  user  deletes  a  window,  the  window  is  removed  from 
the  screen  and  the  memory  which  had  been  assigned  to  that  window  is  made  inaccessible.  This  is 
done  by  enforcing  a  high-water-mark  mechanism  for  each  window’s  address  space.  Second,  all  user- 
modiBable  memory  is  cleared  at  the  end  of  a  user’s  terminal  session;  the  terminal  detects  the  Data 
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Terminal  Ready  signal  (DTR)  drop,  and  upon  that  signal  will  zero  its  memory. 

During  a  login  session  on  the  630  MTG,  all  memory  allocated  for  buffers,  strcks  and  other  630  MTG 
system  objects,  is  zeroed  out  by  the  allocation  lOut.'nes  a//oc  and  gcalloc. 

3.2.3  Conciiision 

System  V/MLS  satisfies  the  B1  Object  Reuse  requirement. 

3.3  Labels 

3.3.1  Requirement 

Sensitivity  labels  associated  with  each  subject  and  storage  object  under  it  control  (e.g., 
process,  file,  segment,  device)  shall  be  maintained  by  the  TCB.  These  labels  shall  be  used  as 
the  basis  for  mandatory  access  control  decisions.  In  order  to  import  non-labeled  data,  the 
TCB  shall  request  and  receive  from  an  authorized  user  the  security  level  of  the  data,  and  all 
such  actions  shall  be  auditable  by  the  TCB. 

3.3.2  Applicable  Features 

System  V/MLS  uses  the  UNDC  group  ID  to  implement  its  labeling  scheme  as  described  in  the 
system  overview  (see  page  45,  'Labels  on  System  V/MLS").  Group  IDs  are  present  in  all  subject 
and  object  structures.  Mandatory  aM:cesa  controls  are  enforced  based  on  these  labels  as  previously 
described  on  page  44,  'Mandatory  Access  Control'.  Non-labeled  data  which  must  be  imported  onto 
the  system  is  initially  labeled  at  SYSHI  until  proper  labeling  can  be  done  by  a  system  administrator. 

3.3.2.1  Labeling  on  the  630  MTG  Terminal 

Labeling  and  the  various  sub-requirements  associated  with  assuring  the  existence  of  trusted  labels 
for  all  storage  objects  at?  handled  by  the  630  MTG  terminal.  There  are  many  operations  in  which 
the  630  MTG  terminal  is  required  to  enforce  the  labeling  requirements.  These  fall  into  two 
categories;  terminal  operations  and  data  manipulation  operations.  In  the  case  of  terminal  operations 
(e.g.,  open  window,  delete  window),  the  630  MTG  terminal  communicates  with  the  host  computer 
via  the  xtO  port.  In  the  case  of  data  manipulation  operations  (e.g.,  cut,  paste),  the  terminal  ensures 
the  integrity  of  the  labels  on  those  window  buffers  at  all  times.  The  630  MTG  ensures  the  integrity 
of  human-readable  labels  attached  to  each  window  buffer  present  on  the  terminal. 

3.3.3  Conclusioii 

System  V/MLS  satisfies  the  B1  Labels  requirement. 

3.4  Label  Integrity 

3.4.1  Reqnirement 

Sensitivity  labels  shall  accurately  represent  srcurity  levels  of  the  specific  subjects  or  objects 
with  which  they  are  associated.  When  exported  by  the  TCB,  sensitivity  labels  shall  accurately 
and  unambiguously  represent  the  internal  labels  and  shall  be  associated  with  the  information 
being  exported. 

3.4.2  Applicable  Features 

Sensitivity  labels  which  are  assigned  to  all  subjects  and  objects  are  described  in  the  system  overview 
(see  page  45,  "Labels  on  System  V/MLS").  The  GIDs,  which  are  stored  internally  in  the  user  area, 
point  to  the  actual  label  which  is  stored  in  internal  kernel  tables.  When  data  files  are  exported  in 
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System  V/MLS  they  are  accompanied  by  their  GIDs.  Procedurjilly,  they  must  also  be  accompanied 
by  the  /mls/labels  mapping  of  those  GIDs  into  their  associated  labels.  For  a  discussion  of  the 
integrity  of  labels  on  the  630  MTG  terminal  (see  page  74,  'Window  Labels'). 

3.4.3  Canchuion 

System  V/MLS  satisfies  the  B1  Label  Integrity  requirement. 

3.6  Exportation  of  Labeled  Infarmation 

3.5.1  Requirement 

The  TCB  shtill  designate  each  communication  channel  and  I/O  device  as  either  single-level 
or  multilevel.  Any  change  in  this  designation  shall  be  done  manually  and  shall  be  auditable  by 
the  TCB.  The  TCB  shall  maintain  and  be  able  to  audit  any  change  tn  the  current  security 
level  or  levels  associated  with  a  communication  channel  or  I/O  device. 

3.5.2  Applicable  Features 

Secondary  storage  devices  (such  as  disk  or  cartridge  tape)  on  System  V/MLS  are  multilevel.  All 
other  devices  except  the  630  MTG  terminal  are  single-level.  The  interface  to  devices  is  via  an 
unambiguously  labeled  special  file  located  in  the  /dev  SECURED  directory.  Any  changes  to  the 
level  of  device  flies  (and  thus  to  their  associated  device)  are  auditable. 

The  630  MTG  terminal  is  treated  as  a  multi-level  device  corresponding  to  multiple  single-level 
pseudodevices.  The  TCB  maintains  the  clearance  range  of  each  terminal  port  in  the  data  file 
/mis/cleardev,  aU  changes  to  this  file  are  auditable  events.  Additionally,  events  which  change  the 
security  level  associated  with  a  630  MTG  terminal  session  may  be  audited. 

3.5.3  Canchuion 

System  V/MLS  satisfies  the  B1  Exportation  of  Labeled  Information  requiremeut. 

3.6  Exportation  to  Mnltiievei  Devices 

3.6.1  Requirement 

When  the  TCB  exports  an  object  to  a  multilevel  I/O  device,  the  sensitivity  label  associated 
with  the  object  shall  also  be  exported  and  shall  resided  on  the  same  physical  medium  as  the 
exported  information  and  sh<Ul  be  tn  the  same  form  (i.e.,  machine-readable  or  human- 
readable  form).  When  the  TCB  exports  or  imports  an  object  over  a  multilevel 
communication  channel,  the  protocol  used  on  that  channel  shcUl  provide  for  the  unambiguous 
pairing  between  the  sensitivity  labels  and  the  associated  information  that  is  sent  or  received. 

3.6.2  Appiicabie  Features 

Multilevel  devices  are  labeled  with  a  maximum  and  minimum  label.  Access  to  multilevel  I/O  device 
flies  wiU  be  restricted  to  processes  that  enforce  the  labeling  requirements  (e.g.  printer  daemons, 
archiving  programs,  630  MTG  pseudodevice  driver). 

The  630  MTG  terminal  conforms  to  this  requirement  by  maintaining  a  virtual  terminal  connection 
which  is  dedicated  to  information  used  for  window  control  and  data  labeling.  Each  window  on  the 
630  MTG  terminal  is  displayed  with  a  tamperproof  header  which  contains  its  mandatory  access 
control  attributes. 
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Data  can  only  b«  imported /exported  to  a  floppy  disk  by  the  system  administrator  through  the 
backup  or  cpio  commands.  Data  files  are  imported/exported  with  their  GIDs.  They  must  abo  be 
accompanied  by  the  /mls/labels  mapping.  This  is  done  via  an  administrative  procedure. 

3.6.3  Conchuian 

System  V/MLS  satisfies  the  B1  Exportation  to  Multilevel  Devices  requirement. 

3.7  Exportation  to  Single-Level  Devices 

3.7.1  Reqoirement 

Single-level  I/O  devices  and  single-level  communication  channels  are  not  required  to 
maintain  the  sensitivity  labels  of  the  information  they  process.  However,  the  TGB  shall 
include  a  mechanism  by  which  the  TCB  and  an  authorised  user  reliable  communicate  to  the 
designate  the  single  security  level  of  information  imported  or  exported  via  single-level 
communication  channels  or  I/O  devices. 

3.7.2  Applicable  Features 

Facilities  within  chpriv,  newpriv,  and  device-dependent  functions  provide  reliable  means  by  which 
authorized  users  may  alter  the  level  associated  with  single-level  devices.  Devices,  including  tty 
devices,  normally  reside  in  the  /dev  directory.  Single  level  devices,  while  in  use,  reside  in  exactly 
one  SECURED  subdirectory  of  /dev.  A  single  level  device  is  only  visible  to  a  user  if  the  device 
resides  in  the  SECURED  subdirectory  of  /dev  which  corresponds  to  the  user’s  current  operating 
level.  A  user  operating  as  root  or  in  the  group  SECURED  sees  the  "real'  /dev  directory  as  well  as 
all  subdirectories. 

The  device  clearances  file,  /rrds/  clear  dev,  specifies  the  maximum  and  minimum  permitted  labels  for 
the  device.  (Actually  /mls/cleardev  specifyes  the  maximum  and  minimum  labels  for  the  port  —  but 
in  a  hardwired  configuration  we  can  identify  the  port  with  the  device.)  At  login  the  maximum  and 
minimum  for  the  session  are  computed  from  the  maximum  and  minimum  of  the  port  and  user;  thb 
maximum  and  minimum  are  stored  in  the  sessions  database  and  are  used  by  newpriv  and  chpriv  to 
determine  if  the  requested  device  reclassification  is  permitted. 

At  login  the  user’s  tty  device  is  assigned  the  user’s  login  label  and  is  placed  in  the  appropriate 
SECURED  subdirectory  of  /dev.  Any  subsequent  changes  in  the  label  assigned  to  the  tty  by  the 
user  must  be  initiated  by  a  trusted  process,  newpriv,  which  re-labeb  the  tty  line  to  reflect  the 
current  label  of  the  user’s  process,  and  moves  the  tty  to  the  appropriate  SECURED  subdirectory. 
Newpriv  consults  the  sessions  database  to  ensure  that  the  requested  new  operating  label  is  permitted 
to  both  the  user  and  the  tty.  Every  read  and  write  to  a  tty  line  is  verified  to  conform  to  MAC 
policy.  Reads  and  writes  to  /dev/tty  are  checked  for  both  MAC  and  DAC. 

Chpriv  can  also  be  used  to  change  the  security  classification  of  a  single-level  device.  Only  a  user 
operating  with  a  real  UID  of  root  will  be  permitted  to  use  chpriv  to  change  the  security  classification 
of  a  character  device. 

Lpsched  is  the  process  which  actually  transmits  files  to  the  printer.  Before  sending  the  file,  Ipsched 
executes  newpriv  to  change  the  classification  of  the  printer  device  to  that  of  the  file  to  be  printed. 
The  labels  of  the  printer  and  the  file  are  identical  for  the  duration  of  the  print  job.  At  the 
conclusion  of  the  print  job  the  printer  is  reclassified  to  SYSTEM. 
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S.7.3  Ckmchision 

System  V/MLS  satisfies  the  B1  Exportation  to  Single-Level  Devices  req'  irement. 

3.8  Labeling  Human-Readable  Output 

3.8.1  Requirement 

The  ADP  system  shall  be  able  to  specify  the  printable  label  names  associated  with  exported 
sensitivity  labels.  The  TGB  shall  mark  the  beginning  and  end  of  all  human-readable,  paged, 
hardcopy  output  (  e.g.,  line  printer  output)  with  human-readable  sensitivity  labels  that 
properly^^  represent  the  sensitivity  of  the  output.  The  TGB  shall,  by  default,  mark  the  top 
and  bottom  on  each  page  of  human-readable,  paged,  hardcopy  output  (e.g.,  line  printer 
output)  with  human-readable  sensitivity  labels  that  properly  represent  the  overall  sensitivity 
of  the  information  on  the  page.  The  TGB  shall,  by  default  and  tn  an  appropriate  manner, 

mark  other  forms  of  human-readable  output  (e.g.,  maps,  graphics)  with  human-readable 

sensitivity  labels  that  properly  represent  the  sensitivity  of  the  output.  Any  override  of  these 
marking  defaults  shall  be  auditable  by  the  TGB. 

3.8.2  Ap^^Ucable  Features 

System  V /MLS  is  capable  of  providing  human-readable  output  in  three  ways:  line  printer  output  via 
the  Ip  command;  displayed  in  a  window  on  the  630  MTG  terminal;  and  displayed  on  a  'dumb' 
terminal,  such  as  the  AT&T  Teletype  4426  or  605  terminals. 

In  the  event  that  the  output  is  provided  by  the  use  of  the  Ip  command,  the  Ip  subsystem  ensures 
that  banner  pages  are  printed  for  each  job  which  display  the  current  label  of  the  user.  A  job  may 
contain  several  files  at  different  levels  from  a  single  user.  The  label  on  the  banner  and  trailer  pages 
of  the  whole  print  job  will  be  the  current  label  of  the  user  and  will  therefore  always  dominate  the 

label  of  any  file  contained  in  the  job.  Additionally,  top  and  bottom  page  labels  are  provided  by 

default;  however,  these  may  be  overridden  by  the  user.  In  the  event  that  these  are  overridden,  the 
act  of  overriding  them  is  auditable.  The  top  and  bottom  labels  are  not  printed  if  the  label  is  longer 
than  80  characters.  In  this  case  the  top  and  bottom  labels  are  replaced  by  the  character  string 
**  security  label  for  privilege  <priv  name>  is  too  long  to  print  ** 
where  <priv  name>  is  the  name  of  the  user’s  current  operating  privilege.  This  label  replacement  is 
auditable. 

The  630  MTG  terminal  labels  all  windows  with  their  sensitivity  label.  The  label  display  is 
dependent  upon  the  sise  of  the  window.  The  hierarchical  portion  of  the  label  is  always  displayed,  as 
is  as  much  of  the  non-hierarchical  portion  of  the  label  as  possible.  In  the  event  that  the  non- 
hierarchical  part  of  the  label  is  too  long  to  be  displayed,  the  630  MTG  flags  the  condition  in  the 
user’s  display,  and  provides  an  option  which  allows  a  user  to  display  the  entire  label. 

By  default,  the  user’s  current  level  and  privilege  are  defined  as  each  user’s  prompt  in  /etc/profile. 
However,  since  users  may  select  their  own  prompts,  they  may  choose  not  to  display  their  current 


15.  The  hierarchical  classification  component  in  human-readable  sensitivity  labels  shall  be  equal  to  the  greatest  hierarchical 
classification  of  any  information  in  the  output  that  the  labels  refer  to;  the  non-hierarchical  category  component  shall 
include  all  of  the  non-hierarchical  categories  of  the  information  in  the  output  the  labels  refer  to,  but  no  other  non- 
hierarchical  categories. 
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level  and  privilege  at  all  times.  Also,  if  the  default  PSl  prompt,  as  defined  in  /etc/profile  would  be 
more  than  240  characters  long,  it  is  replaced  by  *<label  too  long>  privname  $*  where  privname  is 
the  name  of  the  user’s  current  operating  privilege.  For  these  reasons.  System  V/MLS  provides  a 
mechanism  to  display  the  user’s  current  operating  privilege  at  any  time. 

3.8.3  Conchision 

System  V/MLS  satisfies  the  Bl  Labeling  Human-Readable  Output  requirement. 

3.9  Subject  Sensitivity  Labels 

3.9.1  Requirement 

The  TGB  shaU  immediately  notify  a  terminal  user  of  each  change  in  the  security  level 
associated  with  that  user  during  an  interactive  session.  A  terminal  user  shtdl  be  able  to  query 
the  TGB  as  desired  for  a  display  of  the  subject’s  complete  sensitivity  label. 

3.9.2  Applicable  Features 

Terminal  users  may  change  their  current  operating  privilege  (mandatory  label,  discretionary  group 
pair)  during  an  interactive  session  via  the  newpriv  or  exit  (or  CNTL-D)  commands.  These 
commands  print  to  the  screen  the  new  label  of  the  user.  In  addition,  the  user’s  default  prompt  string 
is  used  to  store  the  user’s  current  operating  label;  this  prompt  can  be  modified  by  the  user  to 
contain  any  string.  When  newpriv  or  exit  is  invoked  from  a  host  connected  630  MTG  terminal,  the 
new  label  replaces  the  old  label  in  the  label  bar  for  that  window.  Terminal  users  can  request  that 
the  TCB  display  their  current  sensitivity  label  with  the  'labels  -u'  command.  These  mechanisms  are 
explained  in  detul  on  page  51,  'Changing  Subject  Sensitivity  Label  Interactively'  and  page  74, 
'Window  Labels'. 

3.9.3  Conchuian 

System  V/MLS  satisfies the  B2  Subject  Sensitivity  Labels  requirement. 

3.10  Device  Labels 

3.10.1  Requirement 

The  TGB  shall  support  the  assignment  of  minimum  and  maximum  security  levels  to  all 
attached  physical  devices.  These  security  levels  shall  be  used  by  the  TGB  to  enforce 
constraints  imposed  by  the  physical  environment  in  which  the  devices  are  located. 

3.10.2  AppUcable  Features 

By  invoking  the  mkdevclr  command,  the  system  administrator  can  enter  into  the  /mis/ cleardev  file 
the  maximum  and  minimum  levels  at  which  a  device  may  operate.  Thereafter,  the  device  is 
restricted  to  operate  within  that  range  of  levels.  Maximum  and  minimum  levels  may  be  assigned  to 
all  devices  in  the  evalu^ed  configuration. 


16.  Althon^  System  V/MLS  satisfies  this  requirement  at  the  B2  level,  it  does  not  satisfy  the  assurance  requirements  above 
its  rated  level. 
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3.10.S  Conchuion 

System  V/MLS  satisfies*^  the  B2  Device  Labels  requirement. 

3.11  Mandatary  Access  Control 

3.11.1  Requirement 

The  TGB  shall  enforce  a  mandatory  access  control  policy  over  all  subjects  and  storage  objects 
under  its  control  (e.g.,  processes,  files,  segments,  devices).  These  subjects  and  objects  shaM 
be  assigned  sensitivity  labels  that  are  a  combination  of  hierarchical  classification  levels  and 
non-hierarchiced  categories,  and  the  labels  shall  be  used  as  the  basis  for  mandatory  access 
control  decisions.  The  TGB  shall  be  able  to  support  two  or  more  such  security  levels.  The 
following  requirements  shall  hold  for  all  accesses  between  subjects  and  objects  controlled  by 
the  TGB:  A  subject  can  read  an  object  only  if  the  hierarchical  classification  in  the  subject’s 
security  level  is  greater  than  or  equeU  to  the  hierarchical  classification  in  the  object’s  security 
level  and  the  non-hierarehicai  categories  in  the  subject’s  security  level  include  all  the  non- 
hierarchical  categories  in  the  object’s  security  level.  A  subject  can  write  an  object  only  if  the 
hierarchical  classification  in  the  subject’s  security  level  is  less  that  or  equal  to  the 
hierarchical  classification  in  the  object’s  security  level  and  all  the  non-hierarehical  categories 
in  tile  subject’s  security  level  are  included  in  the  non-hierarchical  categories  in  the  object’s 
security  level.  Identification  and  authentication  data  shall  be  used  by  the  TGB  to 
authenticate  the  user’s  identity  and  to  ensure  that  the  security  level  and  authorization  of 
subjects  external  to  the  TGB  that  may  be  created  to  act  on  the  behalf  of  tiie  individual  user 
are  dominated  by  the  clearance  and  authorization  of  that  user. 

3.11.2  Applicable  Features 

System  V/MLS  enforces  a  mandatory  security  policy  over  all  subjects  and  storage  objects.  This 
security  policy  maintains  protection  of  objects  such  that  no  unauthorised  subject  is  permitted  to 
read  or  write  objects  (in  this  context,  unauthorised  means  that  the  subject  is  executing  at  an 
inappropriate  security  level). 

The  mandatory  security  policy  enfcu-ced  by  System  V/MLS  relies  upon  two  basic  relationships 
between  the  labels  associated  with  subjects  and  objects  -  dominance  and  equivalence: 

Label  X  dominates  (>=)  label  Y  when  the  hierarchical  portion  of  label  X  is  greater 

than  or  equal  to  the  hierarchical  portion  of  label  Y, 
and  label  X  contains  at  least  all  of  the  non- 
hierarchical  categories  that  are  contained  in  label  Y. 

Label  X  is  equivalent  (==)  to  label  Y  when  the  hierarchical  portion  of  label  X  is  identical 

to  the  hierarchical  portion  of  label  Y,  and  the  set  of 
non-hierarchical  categories  contained  in  label  X  is 
identical  to  the  set  of  non-hierarchical  categories 
contained  in  label  Y. 

17.  Althongh  System  V/MLS  satisfies  this  reqairement  at  the  B2  level,  it  does  Dot  satisfy  the  assurance  requirements  above 
its  rated  level. 
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The  mandatory  controls  placed  upon  the  System  V/MLS  objects  are  as  follows: 

-  Files,  directories 

Read  Access:  Subject  >=  Object 

Execute  Access:  Subject  >=  Object 

Write  Access:  Subject  ==  Object 

-  Named  pipes,  unnamed  pipes 

Read  Access:  Subject  >=  Object 

Write  Access:  Subject  ==  Object 

-  Processes  signaling  other  processes 

Read  Access:  Not  Applicable 

Write  Access:  Subject  (sending  proc)  ==  Object  (receiving  proc) 

-  Message  queues,  semaphores,  shared  memory 

Read  Access:  Subject  >=  Object 

Write  Access:  Subject  ==  Object 

Identification  and  authentication  data  is  determined  at  login  and  stored  in  /mla/ sessions.  When  a 
user  invokes  a  program,  including  SUID  and  SGID  programs,  to  act  on  his  or  her  behalf,  the  exee 
system  call  ensures  that  the  sensitivity  level  of  the  process  dominates  the  sensitivity  level  of  the 
program.  In  addition,  the  invoking  process’s  sensitivity  level  is  preserved. 

3.11.2.1  MAC  and  the  630  MT6  Temdnal 

The  portion  of  the  TGB  which  runs  in  the  630  MTG  terminal  enforces  System  V/MLS  mandatory 
access  policy  on  the  630  MTG.  The  implementation  of  this  feature  is  discussed  on  page  77,  'Cut  and 
Paste'. 

3.11.3  Conchisian 

System  V/MLS  satisfies  the  B1  Mandatory  Access  Control  requirement. 

3.12  Identification  and  Authentication 

3.12.1  Reqnirement 

The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning  to  perform  any 
other  actions  that  the  TGB  is  expected  to  mediate.  Furthermore,  the  TCB  shall  maintain 
autiientication  data  that  includes  information  for  verifying  the  identity  of  individual  users 
(e.g.,  passwords)  as  well  as  information  for  determining  the  clearance  and  authorizations  of 
individual  users.  This  data  shall  be  used  by  the  TCB  to  authenticated  the  user’s  identity  and 
to  ensure  that  the  security  level  and  authorizations  of  subjects  external  to  the  TCB  that  may 
be  created  to  act  on  behalf  of  the  individual  user  are  dominated  by  the  clearance  and 
authorization  of  that  user.  The  TGB  shall  protect  authentication  data  so  that  it  cannot  be 
accessed  by  any  unauthorized  user.  The  TCB  shall  be  able  to  enforce  individual 
accountability  by  providing  the  capability  to  uniquely  identify  each  individual  ADP  system 
user.  The  TCB  shall  also  provide  the  capability  of  associating  ^is  identity  with  all  auditable 
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actions  taken  by  that  individual. 

3.12.2  Applicable  Features 

System  V/MLS  requires  all  users,  including  system  operators,  to  identify  and  authenticate 
themselves  before  they  are  allowed  to  access  system  resources.  Users  enter  login  IDs  and  passwords 
to  identify  and  authenticate  themselves  to  the  system.  When  a  system  administrator  adds  a  user 
account,  the  TCB  ensures  that  unique  login  IDs  are  provided  on  an  individual  basis. 

Only  system  administrators  may  gain  access  to  the  identification  and  authentication  information 
because  the  TCB  maintains  this  data  within  the  protected  mis  directory.  The  following  Gles  contain 
identification  and  authentication  data:  /mls/passwd,  /mis/ group.  In  addition  to  storing  the 
passwords  in  a  file  inaccessible  to  nonprivileged  users.  System  V/MLS  encrypts  the  passwords. 

To  obtain  superuser  privileges,  administrators  must  first  login  at  designated  terminals  as  non¬ 
privileged  users.  These  terminal  ports  have  a  minimum  device  label  which  is  SYSTEM  level,  which 
is  less  than  the  unprivileged  users’  minimum.  In  addition,  administrators  must  enter  the  su 
command  and  provide  the  superuser  password  in  order  to  acquire  administrative  capabilities. 

3.12.2.1  Identification  and  Authentication  and  the  630  M'^G  Terminal 

After  the  user  is  identified  and  authenticated  by  the  host,  the  terminal  port  is  identified  in  the 
/mls/eleardev  file  as  being  connected  to  a  630  MTG  terminal.  Next,  firmware  modifications  are 
downloaded,  and  layers  is  invoked.  After  the  trusted  channel  0  has  been  established,  one  or  more 
additional  channels  are  created  and  the  user  is  allowed  to  operate  on  the  terminal.  Any  windows 
which  are  created  by  the  user  are  constrained  by  the  system  MAC  policy  explained  on  page  44, 
'Mandatory  Access  Control'. 

3.12.3  Conchision 

System  V/MLS  satisfies  the  B1  Identification  and  Authentication  requirement. 

3.13  Trusted  Path 

3.13.1  Reqnlrement 

The  TCB  shall  support  a  trusted  communication  path  between  itself  and  users  for  initud 
login  and  authentication.  Communications  via  this  path  shall  be  initiated  exclusively  by  a 
user. 

3.13.2  Applicable  Features 

System  V/MLS  supports  a  trusted  communications  path  for  initial  user  login  to  the  system  for  all 
terminal  types  in  the  evaluated  configuration.  In  all  cases,  the  user  is  advised  to  power-cycle  the 
terminal  to  ensure  that  the  trusted  path  is  established  for  the  login  identification  and  authentication 
option  of  changing  their  password  via  this  trusted  path  mechanism,  through  the  use  of  an  argument 
to  the  login  command.  Users  should  be  encouraged  to  change  their  passwords  through  this  interface 
rather  than  by  use  of  the  passwd  command. 

3.13.3  Canchuiaii 

System  V/MLS  satisfies**  the  B2  Trusted  Path  requirement. 


Revision  10.5 


-91- 

eval  Bl.mm 


(Revised  6/27/91) 


Final  Evaluation  Report  ATIcT  System  V/MLS 
Evaluation  as  a  B1  system 


3.14  Audit 

3.14.1  Requirement 

The  TGB  sh<dl  be  able  to  create,  mamtain,  and  protect  from  modification  or  unauthorized 
access  or  destruction  an  audit  trail  of  accesses  to  the  objects  it  protects.  The  audit  data  shall 
be  protected  by  the  TGB  so  that  read  access  to  it  is  limited  to  those  who  are  authorized  for 
audit  data.  The  TGB  shall  be  able  to  record  the  following  types  of  events;  use  of 
identification  and  au^entication  mechanisms,  introduction  of  objects  into  a  user’s  address 
space  (e.g.,  file  open,  program  initiation),  deletion  of  objects,  actions  taken  by  computer 
operators  and  system  administrators  and/or  system  security  officers,  and  other  security 
relevant  events.  The  TGB  shall  also  be  able  to  audit  any  override  of  human-readable  output 
markings.  For  each  recorded  event,  the  audit  record  shall  identify:  date  and  time  of  the 
event,  user,  type  of  event,  and  success  or  failure  of  the  event.  For 
identification/authentication  events  the  origin  of  request  (e.g.,  terminal  ID)  shall  be  included 
tn  the  audit  record.  For  events  that  introduce  an  object  into  a  user’s  address  space  and  for 
object  deletion  events  the  audit  record  shaU  include  the  name  of  the  object  and  the  object’s 
security  level.  The  ADP  system  administrator  shall  be  able  to  selectively  audit  the  actions  of 
any  one  or  more  users  based  on  individual  identity  and/or  object  security  level. 

3.14.2  Applicable  Features 

The  audit  trail  is  a  file  consisting  of  a  header  and  audit  records.  The  header  provides  general 
information:  identity  of  the  system  this  audit  trail  was  generated  on  and  the  time/date  the  system 
was  brought  into  multi-user  state.  The  header  information  also  provides  a  user  name  map,  a  group 
name  map,  a  label  name  map,  a  terminal  name  map,  and  a  filesystem  map.  These  maps  provide  a 
translation  between  internal  and  human-readable  names.  In  System  V/MLS  the  audit  trail  is 
protected  at  SYSHI. 

Each  audit  record  has  2  parts:  a  header  followed  by  a  data  block  specific  for  that  auditable  event. 
Audit  records  are  sequenced  so  that  missing  records  can  be  detected.  The  header  consists  of  the 
channel  number,  the  number  of  bytes  in  the  record,  the  process  ID  of  the  process  writing  the  record, 
and  a  time  stamp.  The  structure  of  each  audit  record  is  dependent  on  the  type  of  event  being 
recorded. 

Currently  23  channels  are  used  for  the  following  kernel  probe  points.  Subchannels  which  record 
kernel  functions  are  indicated  by  indenting  them  beneath  their  channel. 

sat_accs:  open  for  read /write  access  to  a  filesystem  object  granted 

sat  accf:  open  for  read /write  access  to  a  filesystem  object  denied 

8at_chown:  modification  of  the  owner  of  a  file 

8at_chgrp:  modification  of  the  discretionary  group  of  a  file 

8at_chmod:  modification  of  the  mode  bits  of  a  file  system  object 


18.  Although  Systrni  V/MLS  satisfies  this  rcquiremeut  at  the  B2  level,  it  does  not  satisfy  the  assurance  requirements  above 
its  rated  level. 
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reset  of  system  clock 

sat_8tartnp:  record  current  time  I 

8at_reclas: 

reclassification  of  file 

8at_exece: 

successful/failed  execs 

8at_exit: 

exit  status  of  process 

8at_fork: 

process  fork 

8at_ipcacc8: 

successful  open  for  read/write  access  of  IPC  object 

8at_ipcaccf: 

failed  open  attempts  for  read /write  access  to  IPC  objects 

8at_ipccreat: 

creation  of  an  IPC  object 

8at_ipcchown: 

change  of  the  owner  of  an  IPC  object 

8at_ipcchgrp:  change  of  the  discretionary  group  of  an  IPC  object 

8at_ipcchmod:  change  of  the  mode  bits  of  an  IPC  object 

sat_ipcreclas: 

reclassification  of  IPC  object 

8at_ipcrm: 

removal  of  an  IPC  object 

8at_kiU: 

all  signals  sent  by  privileged  processes 

sat_link: 

new  Unks  to  existing  files 

8at_mknd: 

creation  of  file 

8at_monnt: 

mount  of  local  filesystem 

8at_unmoant;  unmount  of  filesystem 

8at_pipe; 

creation  of  unnamed  pipes 

8at_8err: 

system  calls  that  fail 

8at_8etuid: 

modification  of  effective  UID  of  a  process 

8at_8etgid: 

modification  of  effective  GID  of  a  process 

8at_uli: 

data  written  to  sat  devices 

8at_ulrm: 

removal  of  file  or  directory 

There  are  14  user  level  audit  trail  probes: 

mkuser: 

adding  a  new  user 

rmuser: 

removal  of  a  user 

mklbl: 

creation  of  a  new  label 

mkgrp: 

addition  of  a  new  group  or  new  privilege 

rmpriv; 

removal  of  a  group  or  privilege 
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maxclear:  changes  in  a  user’s  clearance 

addpriv:  addition  of  new  users  to  a  group  /  privilege 

delpriv:  removal  of  users  &om  a  group  /  privilege 

modpriv:  record  rename  of  privilege  or  transfer  of  ownership. 

5310;  suppression  of  labels  on  5310  printer  output, 

mount:  the  inode-name  map  of  the  filesystem  being  mounted 

passwd:  records  the  change  of  a  user’s  password 

mkdevclr:  addition  of  a  new  device  clearance 

rmdevclr:  removal  of  a  device  clearance 

login:  unsuccessful  login  attempts’* 

layers:  records  successful  and  failed  reclassifications  on  630  MTG. 

System  V/MLS  contains  an  audit  trail  formatter,  aatfmt,  which  formats  the  records  in  the  audit 

trail  in  one  of  3  formats:  raw,  verbose  and  sensitive.  Raw  mode  outputs  the  audit  record 

information  completely  in  numeric  characters  in  decimal  rather  than  hex.  Verbose  mode  converts  all 
numeric  references  to  symbolic  names  wherever  possible.  Sensitive  mode  outputs  only  those  events 
defined  as  security  sensitive  and  which  are  of  special  interest  to  the  security  administratm*  (e.g., 
failed  access  attempts). 

Satfmt  maintains  an  internal  name  map  data  structure  for  each  object  defmed  on  the  system, 
including  complete  name  maps  for  all  mounted  filesystems.  This  allows  for  path  resolution  to  be 
determined  quickly,  without  having  to  reference  the  actual  file  system.  In  addition,  when  the  object 
has  multiple  links  all  path  names  are  listed  in  verbose  output.  Also,  satfmt  with  the  -N  option  is  the 
poet-selection  tool  for  choosing  actions  of  a  particular  individual.  System  Administrators  may 
selectively  audit  based  on  the  object  security  level  by  using  grep  on  the  audit  trail  file.  Instructions 
for  using  grep  in  this  manner  exist  in  the  TFM. 

When  the  currently  active  audit  trail  file  becomes  80%  full,  a  warning  message  is  sent  to  the  system 
console.  When  the  current  audit  file  fills,  the  sataave  daemon  switches  to  the  next  audit  file, 
wrapping  around  to  the  fust  file  when  the  last  file  is  full.  If  the  next  audit  trail  file  is  not  empty, 
the  system  will  go  into  single  user  mode. 

3.14.2.1  Auditing  User  Actions  On  The  630  MTG  Terminal 

All  host  connected  processes  are  subject  to  auditing  on  the  host.  Terminal  operations  (e.g.,  create  a 
window)  are  implicitly  audited.  The  terminal  operations  which  manipulate  data  between  processes 
(e.g.,  cut/paste)  which  results  in  a  declassification  or  the  operation  fails  are  audited  as  a  ULI  reemd 
generated  by  layers.  Successful  terminal  operations  are  not  audited.  Both  of  these  justifications  and 
descriptions  can  be  found  on  page  78,  'Auditing  on  the  630  MTG'.  Logins  on  a  630  MTG  terminal 
device  are  auditable,  as  are  all  other  logins. 

19.  successful  logins  arc  audited  as  combination  of  several  kernel  probe  points  (e.g.  sat_exece,  sat_fork) 
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3.14J  Conchiskm 

System  V/MLS  satisHes  the  Bl  Audit  requirement. 

3.15  System  Architectnre 

5.16.1  Requirement 

The  TCB  shall  maintain  a  domain  for  its  oum  execution  that  protects  it  from  external 
interference  or  tampering  (e.g.,  by  modification  of  its  code  or  data  structures).  Resources 
controlled  by  the  TCB  may  be  a  defined  subset  of  subjects  and  objects  in  the  ADP  system. 
The  TCB  shall  maintain  process  isolation  through  the  provision  of  distinct  address  spaces 
under  its  control.  The  TCB  shall  isolate  the  resources  to  be  protected  so  that  they  are  subject 
to  the  access  control  and  auditing  requirements. 

3.15.2  AppUcable  Features 

The  System  V/MLS  TCB,  which  includes  the  630  MTG  terminal  as  part  of  the  evaluated 
configuration,  meets  the  system  architecture  requirement  by  maintaining  a  domain  for  its  own 
execution  and  maintaining  process  isolation,  both  in  the  host  and  in  the  terminal.  The  host  system 
provides  these  features  via  both  hardware  memory  management  and  kernel  data  structure 
organisation.  As  discussed  previously,  the  system  hardware  supports  both  a  kernel  and  user 
domain,  with  access  to  these  memory  spaces  enforced  by  the  hardware.  System  data  and  code  files 
are  protected  from  modification  by  both  mandatcuy  and  discretionary  policy,  ensuring  that  the 
system  is  not  corrupted.  The  630  MTG  terminal  does  not  provide  hardware  memory  management; 
however,  the  same  functionality  is  achieved  by  ensuring  that  all  code  which  runs  on  the  terminal  is 
trusted.  This  ensures  that  the  execution  domain  of  the  630  MTG  terminal  is  inviolate.  Process 
isolation  is  a  topic  which  is  not  applicable  to  the  630  MTG  terminal,  in  that  the  terminal  executes 
only  one  process  at  a  time,  and  the  processes  which  may  be  executed  are  all  trusted. 

All  objects  and  resources  which  are  supported  by  System  V/MLS  in  its  evaluated  configuration  are 
defined  to  the  TCB  and  exist  under  its  protection.  All  elements  of  the  system  are  protected  by  the 
System  V/MLS  security  policy. 

3.15.3  Ccnchukn 

System  V/MLS  satisfies  the  Bl  System  Architecture  requirement. 

3.16  System  Integrity 
3.16.1  Reqnirenient 

Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to  periodically  validate 
the  correct  operation  of  the  on-site  hardware  and  firmware  elements  of  the  TCB. 

3.16.3  AppOcabk  Features 

A  complete  set  ot  system  integrity  tests  are  shipped  with  the  System  V/MLS  system.  The  test 
facility  is  referred  to  as  the  Diagnostic  Monitor  (DGMON),  and  is  shipped  as  stmidard  equipment 
with  each  3B2  computer.  The  test  facility  is  a  comprehensive  one,  and  as  such  requires  that  the 
system  be  brought  down  to  lirmware  mode  befOTe  the  tests  may  be  run. 

The  DGMON  tests  exercise  the  CPU  (including  the  privileged  instructions),  the  system  board,  the 
memory,  the  Vcache,  and  the  peripheral  device  controUers.  The  tests  and  instructions  for  their 
op«ration  are  diKussed  in  a  manual  which  is  available  to  system  administrators.  This  manual,  the 
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AT&T  SBS  Computer  Off-Line  Diagnoetice  Manual,  provides  s  good  description  of  each  test,  what  it 
covers,  and  how  to  use  it. 

3.16.3  Conchuion 

System  V/MLS  satisfles  the  B1  System  Integrity  requirement. 

3.17  Security  Testing 

3.17.1  Requirement 

The  security  mechanisms  of  the  ADP  system  shall  6e  tested  and  found  to  work  as  claimed  in 
the  system  documentation.  A  team  of  individuals  who  thoroughly  understand  the  specific 
implementation  of  the  TCB  shall  subject  its  design  documentation,  source  code,  and  object 
code  to  thorough  analysis  and  testing.  Their  objectives  shall  be:  to  uncover  all  design  and 
implementation  flaws  Aat  would  permit  a  subject  external  to  the  TCB  to  read,  change,  or 
delete  data  normally  denied  under  the  mandatory  or  discretionary  security  policy  enforced  by 
the  TCB;  as  well  as  to  assure  that  no  subject  (without  authorisation  to  do  so)  is  able  to  cause 
the  TCB  to  enter  a  state  such  that  it  is  unable  to  respond  to  communications  initiated  by 
other  users.  All  discovered  flaws  shall  be  removed  or  neutralised  and  the  TCB  retested  to 
demonstrate  that  they  have  been  eliminated  and  that  new  flaws  have  not  been  introduced. 

3.17.2  Applicable  Features 

3.17.2.1  Overview  of  Vendor  Test  Suite 

The  complete  AT&T  System  V/MLS  test  suite  consists  of  three  distinct  parts:  the  security  test 
suite,  the  functional  tests,  and  the  630  MTG  terminal  test  suite.  Although  there  are  several 
instances  where  security  tests  and  functional  tests  may  overlap,  AT&T  felt  it  was  impmtant  to 
separate  the  two  and  perform  each  set  independen^  of  the  other.  The  630  MTG  terminal  tests  are 
also  separated  into  both  security  and  functional  tests  and  are  discussed  later. 

The  System  V/MLS  security  tests  are  aimed  at  ensuring  that  all  B1  security  requirements  as  stated 
in  the  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  are  met.  These  tests 
are  broken  into  the  following  six  sections  of  the  requirements:  discretionary  access  control,  object 
reuse,  labeling,  mandatory  access  control,  identification  and  authentication,  and  audit. 

The  functional  tests  ensure  that  the  System  V/MLS  software  functions  correctly  as  described  in  the 
system  documentation.  These  tests  are  broken  into  the  following  sections: 

1.  Section  (1)  System  V  User  and  Administrative  Command  Tests 

2.  Section  (IS)  System  V/MLS  Security  Enhanced  or  New  User  &  Administrative  Command 
Tests 

3.  Section  (2)  System  V  System  Call  Tests 

4.  Section  (2S)  System  V/MLS  Security  Enhanced  or  New  System  Call  Tests 

5.  Long  Labels  Tests 

Testing  of  the  trusted  processes  is  included  in  the  functional  testing. 

The  630  MTG  terminal  has  its  own  test  plan  and  procedures  to  test  its  functional  and  security 
properties.  The  underlying  philosophy  of  the  630  MTG  tests  paraUeb  the  philosophy  used  by  the 
System  V/MLS  tests;  namely,  that  functional  tests  are  constructed  fcv  functions  advertised  in  the 
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User’s  Guide  and  security  tests  are  constructed  from  TCSEC  requirements.  The  System  V/MLS 
tests  are  first  run  on  the  630  MTG  to  ensure  that  there  is  nothing  specific  to  the  630  MTG  terminal 
that  affects  the  system.  The  goal  of  the  630  MTG  test  plan  is  to  assure  that  System  V/MLS 
security  policy  is  enforced  when  a  user  is  using  the  terminal.  The  630  MTG  functional  and  security 
tests  are  performed  as  described  below. 

Functional  testing  for  the  630  MTG  consists  of  tests  for  new  or  modified  commands  that  are 
executed  on  the  host  and  tests  for  630  MTG  specific  functionality  available  through  mouse  menu 
interaction.  Terminal  commands,  or  mouse  selections,  are  each  tested  manually.  These  tests  involve 
such  functions  as  bringing  window  top  and  current,  putting  window  into  local  edit  mode, 
interwindow  data  moves,  creating  local  windows,  creating  new  windows,  moving/reshaping  windows, 
showing  a  window’s  label,  editing  the  programmable  function  keys,  scrolling  and  terminal  reset. 

Security  testing  for  the  630  MTG  consists  of  tests  which  correspond  to  those  TCSEC  requirements 
involving  the  630  MTG.  These  tests  first  cause  certain  operations  to  occur  and  then  observe  the 
effects  or  lack  of  effects  of  these  operations.  No  extra  testing  is  performed  for  DAC  since  the  630 
MTG  introduces  no  additional  discretionary  access  controls. 

3.17.2.2  Additional  User  Testing 

In  addition  to  formal  testing  using  AT&T’s  security  and  functional  tests,  System  V/MLS  was  also 
exercised  on  a  daily  basis  as  AT&T  developers  and  testers  used  the  system  for  both  general 
computing  and  further  development  efforts.  Through  this  regular  usage  of  the  system,  AT&T  gained 
more  assurance  of  the  validity  of  the  system.  In  addition,  as  new  features  were  added  to  System 
V/MLS,  new  tests  were  added  to  the  original  test  suites,  and  some  original  tests  were  modified  as 
necessary  to  exercise  this  current  system. 

3.17.2.3  Vendor  Security  Analyst  (VSA)  Testing 

AT&T’s  Vendor  Security  Analysts  (VSA)  and  test  team  conducted  the  System  V/MLS  testing  on 
AT&T  3B2/500  and  3B2/600  computers  owned  by  AT&T  and  located  at  the  AT&T  site  in 
Whippany,  NJ.  The  test  team  executed  all  of  AT&T’s  automated  and  manual  tests.  The  security 
test  suite  consists  of  4  sets  of  automated  tests  and  4  sets  of  manual  tests.  The  functional  tests 
consist  of  225  automated  and  84  manual  tests.  The  630  Test  Suite  consists  of  120  manual  tests. 

All  tests  were  run  using  Release  1.2.0  of  System  V/MLS  integrated  with  Release  3.1.1  of  UNIX 
System  V.  The  evaluated  software  configuration  consists  of  Release  1.2.0  of  System  V/MLS,  which 
is  Release  1.1.2  with  the  inclusion  of  fixes  and  enhancements  made  during  the  first  Ratings 
Maintenance  Phase  (RAMP)  integrated  with  UNIX  System  V  Release  3.1.1.  The  hardware 
configuration  of  computers  on  which  the  tests  were  run  is  as  follows: 

1.  AT&T  3B2/500  which  includes: 

a.  WE  32100  microprocessor  and  18  MHz  clock  -  CM518A 

b.  WE  32101  Memory  Management  Unit 

c.  WE  32106  Math  Accelerator  Unit  (MAU) 

d.  Virtual  Cache 

e.  Two  4  Mbyte  EGG  RAM  -  CM523A 

f.  147  Mbyte  hard  disk  (Control  Data  Corp.)  -  KS-23371,L17 
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g.  720  Kbyte  floppy  disk  drive  -  KS-23114,L4 

h.  SCSI  Host  Adaptor  Card  -  CM195W 

i.  SCSI  60  Mbyte  (TM/60S)  cartridge  tape  drive  -  KS-23417,L2 

j.  Enhanced  Ports  (EPORTS)  Board  -  CM195Y 

k.  AT&T  4425  Terminal  as  the  System  Console 

l.  AT&T  4426  Terminal  hardwired  to  EPORTS  board 

m.  AT&T  630  MTG  terminal  hardwired  to  EPORTS  board 

n.  AT&T  5310  Dot  Matrix  Printer  hardwired  to  the  CONTTY  port 
2.  AT&T  3B2/600  which  includes: 

a.  WE  32100  microprocessor  and  18  MHz  clock  -  CM518A 

b.  WE  32101  Memory  Management  Unit 

c.  WE  32106  Math  Accelerator  Unit  (MAU) 

d.  Virtual  Cache 

e.  Two  4  Mbyte  ECO  RAM  -  CM523A 

f.  147  Mbyte  hard  disk  (Control  Data  Corp.)  -  KS-23371,L17 

g.  720  Kbyte  floppy  disk  drive  -  KS*23114,L4 

h.  SCSI  Host  Adaptor  Card  -  CM195W 

i.  SCSI  60  Mbyte  (TM/60S)  cartridge  tape  drive  -  KS-23417,L2 

j.  Enhanced  Ports  (EPORTS)  Board  -  CM195Y 

k.  AT&T  605  Terminal  as  the  System  Console 

l.  AT&T  4425  Terminal  hardwired  to  EPORTS  board 

m.  AT&T  630  MTG  terminal  hardwired  to  EPORTS  board 

n.  AT&T  5310  Dot  Matrix  Printer  hardwired  to  the  CONTTY  port 

3.17.2.4  Problems  Uncovered  During  System  Y/MLS  Testing 

The  following  problems  were  uncovered  in  the  software  as  a  result  of  the  testing  effort: 

1.  The  PFKeys  of  the  630MTG,  when  used  in  the  two-host  configuration,  were  not  cleared  when 
one  host  was  exited  and  logged  back  in. 

2.  The  630MTG  terminal  failed  to  sanitise  itself  when  both  host  connections  were  terminated  by 
pulling  the  terminal  connectors  from  the  main  and  auxiliary  ports. 

AT&T  made  software  fixes  for  each  of  the  problems  identified  above,  and  the  final  load  of  Release 
1.2.0  contains  these  Axes.  This  final  load  was  retested  to  verify  that  the  problems  were  corrected 
and  that  no  additional  problems  were  introduced  during  the  process  of  making  the  requisite  fixes. 
The  same  computer  configurations  were  used  for  the  retesting  activity. 
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3.17.3  Candnsion 

System  V/MLS  satisfies  the  B1  System  Testing  requirement. 

3.18  Design  Specification  and  Verification 

3.18.1  Requirement 

A  formal  or  informal  model  of  the  security  policy  supported  by  the  TCB  shall  be  maintained 
over  the  life  cycle  of  the  ADP  system  and  demonstrated  to  be  consistent  with  its  axioms. 

3.18.2  Applicable  Features 

System  V/MLS  implements  a  modified  version  of  the  Bell  and  LaPadula  security  model  to  enforce 
mandatory  security.  The  UNIX  System  V/MLS  implementation  is  more  restrictive  than  the  Bell 
and  LaPadula  model  in  that  write  access  to  an  object  is  only  permitted  when  the  subject  and  object 
have  identical  security  labels.  The  System  V/MLS  security  policy  is  maintained  throughout  the 
system  including  the  630  MTG  terminal. 

3.18.3  Conclnslon 

System  V/MLS  satisfies  the  Bl  Design  Specification  and  Verification  requirement. 

3.19  Security  Features  User's  Guide 

3.19.1  Requirement 

A  single  summary,  chapter  or  manual  in  user  documentation  shall  describe  the  protection 
mechanisms  provided  by  the  TCB,  guidelines  on  their  use,  and  how  they  interact  with  one 
another. 

3.19.2  Applicable  Features 

The  System  V/MLS  User’s  Guide  and  Reference  Manual,  6S0  MTG  User’s  Guide,  SB2  UNIX 
System  V  Programmer’s  Reference  Manual,  and  the  UNIX  System  V  User’s  Guide  coUectively  meet 
the  Security  Features  User’s  Guide  requirements.  These  manuab  are  intended  for  users  and  provide 
descriptions  of  the  functions  of  System  V/MLS. 

The  System  V/MLS  User’s  Guide  and  the  6S0  MTG  User’s  Guide  provide  descriptions  of  and 
guidelines  for  the  use  of  the  protection  mechanisms  provided  by  the  TCB.  They  are  structured  as 
follows: 


3.19.2.1  System  V/MLS  User's  Guide  and  Reference  Manual 

This  manual  consists  of  the  following  three  sections:  System  V/MLS  Policy  Definition,  System 
V/MLS  Tutorial,  and  Manual  Pages  for  System  V/MLS  Commands. 


Section  I 

Defines  the  System  V/MLS  security  policy,  explains  security  labels, 
discretionary  access  control,  and  auditing. 

Section  II 

Describes  the  features  and  general  use  of  System  V/MLS  (e.g.,  login 
procedures,  creating  directories,  making  privileges). 

Section  III 

Contains  the  manual  pages  for  System  V/MLS  (includes  new  and 
modified  commands). 
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3.19.2.2  630  MTG  User’s  Guide 

This  manual  describes  the  modifications  made  to  the  630  MTG  in  order  to  allow  it  to  be  used  within 
a  multi-level  secure  computer  system.  Trustworthy  security  labels  on  windows,  terminal  firmware 
verification  on  login,  and  terminal  memory  clearing  on  logout  are  added  security  relevant  features 
for  the  630  MTG.  In  addition,  this  manual  explains  the  630  MTG  features  which  have  been 
disabled  to  prevent  using  the  terminal  to  circumvent  security. 

3.19.3  Conchisian 

System  V/MLS  satisfies  the  B1  Security  Features  User’s  Guide  requirement. 

3.20  Trusted  Facility  Manual 

3.20.1  Requirement 

A  manual  addressed  to  the  ADP  system  administrator  shall  present  cautions  about  functions 
and  privileges  that  should  be  controlled  when  running  a  secure  facility.  The  procedures  for 
examining  and  maintaining  the  audit  files  as  well  as  the  detailed  audit  record  structure  for 
each  type  of  audit  event  shall  be  given.  The  manual  shall  describe  the  operator  and 
administrator  functions  related  to  security,  to  include  changing  the  security  characteristics  of 
a  user.  It  shall  provide  guidelines  on  the  consistent  and  effective  use  of  the  protection 
features  of  the  system,  how  they  interact,  how  to  securely  generate  a  new  TGB,  and  facility 
procedures,  warnings,  and  privileges  that  need  to  be  controlled  tn  order  to  operated  the 
facility  in  a  secure  manner. 

3.20.2  Applicable  Features 

The  System  V/MLS  Trusted  Facility  Manual,  User’s  Guide  and  Reference  Manual,  System  V  User’s 
Guide,  SB2  System  V  Programmer’s  Reference  Manual,  SB2  System  V  System  Administration 
Utilities  Guide,  6S0  MTG  User’s  Guide,  6S0/MLS  Trusted  Facility  Manual-MultiLevel  Secure 
Window  Management,  and  the  6S0  MTG  User’s  Manual  are  intended  for  use  by  system  operators 
and  administrators.  These  manuals  are  used  to  guide  an  administrator  or  operator  in  the  correct 
way  to  operate  System  V/MLS  in  a  secure  manner,  and  collectively  meet  the  Trusted  Facility 
Manual  requirements. 

3.20.2.1  System  Y/MLS  Trusted  Facility  Manual 

This  manual  consists  of  sections  which  describe  the  procedures  for  operating  the  system  in  a  secure 
manner. 
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Section  I 

Introduces  the  types  of  system  officers  and  explains  how  to  use  this 
guide. 

Section  II 

Describes  the  threats  to  information  security  as  well  as  the  measures 
taken  to  protect  against  these  threats.  Both  internal  and  external 
threats  are  explained. 

Section  HI 

Provides  a  description  of  labeling,  mandatory  access  control, 
discretionary  access  control,  identification  and  authentication,  trusted 
path,  auditing,  and  object  reuse. 

Section  IV 

Explains  the  following:  additional  accountability,  default  path.  Bourne 
shell,  physical  security,  maximum  number  of  file  descriptors,  and 
mandatory  access  control. 

Section  V 

Explains  system  start-up  and  shutdown;  mounting,  unmounting,  and 
storing  labeled  data;  backing  up  and  restoring  files;  maintaining  the 
audit  trail;  and  distributing  labeled  hardcopy. 

Section  VI 

Describes  the  foUovdng:  setting  the  system  time  and  date;  managing 
user  accounts;  installing  and  removing  software;  maintaining  correct 
permissions;  and  granting  special  authorisations. 

Section  VII 

Explains  security  administrator  roles:  administrating  clearance 
information;  securing  directories;  reclassifying  information;  reviewing 
audit  trail  data;  and  installing  and  uninstalling  System  V/MLS. 

Section  VIH 

Includes  appendices  of  setuid  and  setgid  files  that  exist  after  System 
V /MLS  is  installed  and  the  TCB  listing. 

3.20.2.2  630/MLS  Trusted  Facility  Manual 

This  manual  describes  logical  and  physical  connections  to  the  host,  downloading  software,  630 
installation,  DAC,  MAC,  and  object  reuse.  In  addition,  this  manual  describes  accountability,  and 
trusted  communications. 

3.20.3  Conchisian 

System  V/MLS  sattsfies  the  B1  Trusted  Facility  Manual  requirement. 

3.21  Test  Documentation 

3.21.1  Requirement 

The  system  developer  shall  provide  to  the  evaluators  a  document  that  describes  the  test  plan, 
test  procedures  that  show  how  the  security  mechanisms  were  tested,  and  results  of  the 
security  mechanisms’  functional  testing. 

3.21.2  Applicable  Features 

The  System  V/MLS  Test  Plan  describes  the  testing  methodology  employed  by  the  testers  of  the 
System  V/MLS  system.  The  System  V/MLS  test  plan  outlines  their  specific  testing  approach,  which 
consists  of  features  testing  of  all  mechanisms  which  exist  to  satisfy  Criteria  requirements.  The  tests 
are  largely  automated,  with  the  exception  of  tests  for  identification  and  authentication,  and  other 
areas  in  which  manual  intervention  is  required. 
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3.21.S  Conchuiem 

System  V /MLS  satisHes  the  Bl  Test  Documentation  requirement. 

3.22  Design  Documentation 

3.22.1  Requirement 

Documentation  ak(M  be  available  that  providea  a  deacription  of  the  manufacturer *a  philoaophy 
of  protection  and  an  explanation  of  how  thia  philoaophy  ia  tranalated  into  the  TGB.  If  the 
TCB  ia  compoaed  of  diatinct  modulea,  the  interfacea  between  theae  modulea  ahall  be 
deacribed.  An  informal  or  formed  deacription  of  the  aecurity  policy  model  enforced  by  the 
TCB  ahall  be  available  and  an  explanation  provided  to  ahow  Viat  it  ia  aufficient  to  enforce  the 
aecurity  policy.  The  apecific  TCB  protection  mechaniama  ahall  be  identified  and  an 
explanation  given  to  ahow  that  they  aatiafy  the  model. 

3.22.2  Applicable  Features 

There  is  no  one  document  which  purports  to  act  as  complete  design  documentation  for  System 
V/MLS.  Instead,  there  exist  several  distinct  documents,  each  detailing  the  operation  of  some  subset 
of  the  entire  system.  The  documentation  for  the  underlying  UNIX  system  upon  which  System 
V/MLS  is  based  consists  largely  of  Maurice  Bach’s  The  Deaign  of  the  UNIX  Operating  Syatem,  as 
well  as  the  course  notes  from  several  ATAT  UNIX  system  internals  classes. 

The  system  developers  have  also  written  a  series  of  relatively  detailed  papers  which  specifrcally 
discuss  the  operation  of,  and  philosophy  underlying.  System  V/MLS.  Finally,  some  inspection  of 
the  system  source  code  has  shown  that  it  sufricies  as  documentation  for  less  complex  trusted 
processes.  ATAT  developers  have  produced  more  detailed  documentation  in  those  cases  in  which 
the  functionality  of  the  trusted  process  was  not  readily  discernable  from  a  simple  inspection  of  the 
commented  code  and  cross  references. 

3.22.3  Canchuion 

System  V/MLS  satisfies  the  Bl  Design  Documentation  requirement. 

3.23  RAMP 

3.23.1  Requfa-ement 

All  changes  to  the  TCB,  and  its  supporting  evaluation  evidence,  shall  be  identified  and 
analyzed  for  security  relevant  effects.  Procedures  ahtdl  be  in  place  to  ensure,  for  each 
change,  that  all  deaign  documentation,  user  documentation,  source  code,  and  teat  fixtures  are 
updated  appropriately.  A  Rating  Maintenance  Plan  (RMPlan)  ahall  be  provided  which 
describes  the  mechaniama,  procedures,  and  tools  which  will  be  used  m  support  of  the  above 
activities.  A  convincing  argument  ahaU  be  given  to  ahow  the  deacribed  mechaniama, 
procedures,  and  tools  are  aufficient  to  address  all  changes  to  the  TCB,  including  new 
features,  bug  fixes,  and  changes  to  satisfy  evolving  criteria  requirements. 

3.23.2  Applicable  Features 

All  changes  made  to  the  System  V/MLS  product  including  hardware,  software  and  documentation 
are  initiated  through  a  conflguration  control  process.  This  configuration  control  process  ensures  that 
all  efements  (e.g.,  code,  tests,  documents)  effected  by  a  given  change  are  appropriately  modified  and 
analysed.  This  configuration  control  process  (all  mechanisms,  procedures,  and  tools)  is  described  in 
the  Rating  Maintenance  Plan  for  Syatem  V/MLS  (RMPlan). 
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The  configuration  control  process  outlined  in  the  System  V/MLS  RMPlan  was  applied  to  all  changes 
made  to  System  V/MLS  Release  1.1.2  to  produce  System  V/MLS  Release  1.2.0.  RAMP  audits  were 
conducted  by  AT&T  and  RAMP  Audit  Reviews  were  conducted  by  the  NGSC  to  ensure  that  the 
process  was  functioning  properly.  All  evidence  of  the  changes  was  recorded  in  the  Rating 
Maintenance  Report  for  System  V/MLS  Release  i.2.0. 

S.2S.3  Canchuian 

System  V/MLS  satisfies  the  RAMP  requirement. 
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4.  Evahiator’s  Camments 

The  evaluation  team  found  AT&T  System  V /MLS  to  be  a  flexible  general  purpose  operating  system 
when  run  in  its  evaluated  configuration.  During  the  course  of  working  with  the  system,  the  team 
developed  opinions  about  some  of  the  system’s  design  characteristics  and  features.  The  following  are 
several  of  the  team’s  opinions  about  System  V /MLS. 

•  System  V/MLS  is  unique  among  systems  evaluated  by  the  National  Computer  Security  Center 
to  date  in  that  it  allows  use  of  a  urindowing  terminal  (the  630  MTG),  which  is  capable  of 
processing  information  of  differing  sensitivity  levels  simultaneously.  The  team  found  this  to  be 
an  extremely  useful  and  convenient  feature.  In  addition  to  the  630  MTG  terminal’s  ability  to 
protect  information  at  differing  sensitivity  labels  is  the  terminal’s  intrinsic  'smart'  terminal 
functionality  (e.g.  line  re-entry,  'cut  and  paste'  capabilities,  programmable  function  keys),  all  of 
which  operate  within  the  boundaries  defined  by  the  System  V /MLS  security  policy. 

•  If  the  superuser  creates  an  object,  the  Ale’s  mandatory  access  control  label  is  NOT  derived  from 
the  source  of  the  data.  Instead,  the  file  is  labeled  at  SYSTEM  level,  the  lowest  mandatory  access 
control  label  supported  by  the  system.  The  superuser  must  then  explicitly  reclassify  the  object 
to  the  appropriate  sensitivity  label.  For  example,  if  the  superuser  wishes  to  concatenate  two  or 
more  audit  tradl  files  together  in  order  to  produce  a  third  file  containing  all  of  the  audit  data 
from  a  given  day,  then  the  resulting  file,  a  derivative  of  several  Ales  with  the  mandatory  access 
control  label  SYSHI,  will  be  labeled  as  SYSTEM  level.  Although  System  V/MLS  provides  a 
warning  about  this  to  the  administrator  when  the  su  command  is  successfully  invoked,  the  team 
feels  that  undue  care  must  be  taken  by  system  administrators  in  order  to  m^tain  the 
conAdentiality  of  information  which  they  may  access  in  the  course  of  their  duties.  It  should  be 
noted  though  that  discretionary  access  control  is  still  in  place.  The  default  umask  setting  is  for 
owner  access  only. 

•  The  3B2/500,  due  to  the  design  of  its  system  hom'd  and  the  way  that  board  is  Atted  into  its 
chassis,  has  two  separate  console  ports.  It  is  important  that  only  the  console  port  on  the  back  of 
the  machine  be  used. 

•  In  the  event  that  there  is  no  entry  for  a  terminal  device  in  the  /mis/ clear  dev  Ale,  then  the 
clearance  range  of  the  device  is  from  SYSTEM  level  to  SYSHI  -  that  b,  the  entire  range  of  labels 
supported  on  the  machine.  The  team  feels  that  this  b  inappropriate,  and  that  only  devices  with 
valid  /mis/ cleardev  entries  should  be  allowed  any  access  to  the  system.  System  V/MLS  does, 
however,  send  a  message  to  the  system  console  each  time  a  user  logs  into  the  system  from  a 
device  which  has  no  entry  in  the  /mis/ cleardevtUe.  Additionally  it  should  be  noted  that  a  user’s 
operation  on  a  terminal  b  still  limited  to  that  user’s  clearance  range. 

•  The  team  feeb  that  it  b  important  to  note  that  System  V/MLS  loses  NO  audit  data  when  the 
system  audit  log  overflows.  In  thb  case,  the  buffer  contmning  the  audit  data  b  saved  to  a  Ale 
before  the  system  stops  processing  user  programs.  Some  catastrophic  failures,  such  as  a  power 
failure  or  system  panic,  may  cause  up  to  one  buffer  of  audit  data  to  be  lost,  and  buffer  sue  may 
be  selected  such  that  thb  amount  of  data  may  be  made  to  be  the  sue  of  one  audit  record. 

•  The  system  adminbtrator  responsible  for  revbwing  the  audit  data  should  note  that  the  satfmt 
command  option  '^S*,  which  selects  'sensitive'  mode  output,  will  only  inform  the  user  about 
those  events  whkh  the  vendor  of  System  V/MLS  has  defined  as  'sensitive.'  These  events 
exclude  several  occurrences  which  a  prudent  system  admmbtrator  may  And  to  be  security¬ 
relevant.  The  team  recommends  the  use  of  the  '-V'  option,  which  selects  'verbose'  output.  In 
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verbose  mode,  all  of  the  audit  data  is  reported  to  the  administrator,  who  can  then  review  it  for 
events  which  may  be  considered  to  be  of  particular  relevance  to  their  installation.  Verbose  mode 
is  the  default  option  for  satfmt 

•  System  V/MLS  does  support  a  trusted  communications  path  at  login  time  (and,  through  an 
argument  to  the  login  command,  it  supports  a  trusted  path  for  password  change,  as  well).  This 
trusted  path  mechanism  is  simple,  but  effective;  it  is  simply  good  security  practice  for  users  to 
power  off  their  terminals  at  the  end  of  their  login  sessions,  and  this  practice  will  automatically 
invoke  the  System  V/MLS  trusted  path  mechanism. 

•  To  provide  discretionary  access  to  the  level  of  a  single  user,  System  V /MLS  uses  the  traditional 
UNIX  mechanism  of  protection  bits  for  the  file’s  owner,  group,  and  other.  The  inconvenience  of 
this  mechanism  in  excluding  single  users,  needing  to  constantly  modify  groups  as  new  users  gain 
access  to  the  system  or  users  are  deleted  from  the  system  or  group,  as  well  as  the  impossibility  of 
giving  different  users  different  access  rights  to  an  object  have  been  thoroughly  discussed  in  the 
literature  and  are  well  known  within  the  computer  security  community.  However,  the  situation 
is  mitigated  somewhat  in  the  case  of  System  V/MLS  because  the  ordinary  user  can  create  his  or 
her  own  groups  and  privileges,  thereby  being  able  to  tailor  groups  and  group  membership  to 
specific  situations,  even  to  creating  groups  to  the  granularity  of  a  single  file,  if  necessary. 

•  When  a  user  sends  mail  to  another  user  who  is  not  cleared  to  the  label  of  the  message,  the  mail 
still  goes  through.  The  sending  user  is  not  notified  of  the  situation.  The  receiving  user  can  not 
read  that  mail  (and  course  is  not  notified  of  the  mail)  unless  his  or  her  clearance  is  raised  to 
the  label  of  the  message. 
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Appendix  A:  £vahiated  Hardware  CompoiientB 


The  hardware  components  inclnde:  The  3B2/500  and  the  3B2/600  computers,  in  all  configurations, 
provided  that  the  chipset  used  in  the  machine  is  the  WE  32100  series  chipset,  and  not  the  WE 
32200  series.  Machines  equipped  with  the  WE  32200  chipset  were  not  addressed  in  the  course  of 
this  evaluation. 

The  hardware  boards  which  make  up  the  WE  32100  chip  set  are  the  following: 


Comcode 


System  Board 
which  includes: 


Memory  Extension  Boards: 


CM518A 

103984225 

Microprocessor 

WE  32100 

Memory  Management  Unit  (MMU) 

WE  32101 

Math  Accelerator  Unit  (MAU) 

WE  32106 

Cache  Memory 

CM522A 

103984472 

2  Mbyte 

CM523B 

103984605 

4  Mbyte 

CM523A 

103984597 

The  following  interface  boards  may  be  used  to  connect  peripheral  devices  to  the  3B2/600  and 
3B2/600  computers  of  the  evaluated  configuration; 


Comcode 

Ports  Card 

CM195B 

103828620 

HiPorts  Card 

CM195BA 

103985362 

EPorts  Card 

CM195Y 

104166533 

SCSI  Host  Adaptor 

CM195W 

104166525 
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The  following  devices  may  be  used  in  conjunction  with  a  3B2/600  or  3B2/600  while  operating  in  a 
Bldevel  evaluated  configxiration. 


Device  Type 

Capacity 

Interface 

Cmncode 

Fixed  Disk 

94M  byte 

SCSI 

405188616 

Fixed  Disk 

136M  byte 

SCSI 

406188608 

s  Fixed  Disk 

147M  byte 

SCSI 

405209652 

Fixed  Disk 

300M  byte 

SCSI 

405428129 

♦  Cartridge  Tape 

60M  byte 

SCSI 

405267568 

Cartridge  Tape 

120M  byte 

SCSI 

406408147 

0-Track  Tape 

40M  byte 

SCSI  ■ 

405218611 

9-Track  Tape 

160M  byte 

SCSI 

406206848 

*  Floppy  Disk 

720K  byte 

System  Board 

403960876 

Model  4426  Display 

Mono 

EPORTS/PORTS/HIPORTS 

N/A 

Model  605  BCT  Display 

Mono 

EPORTS/PORTS/HIPORTS 

501007850 

Model  630  MTG  Display 

Mono 

EPORTS/PORTS/HIPORTS 

(Graphics/Windowing) 

Monitor 

601001697 

Controller 

601001671 

Mouse 

624694167 

Keyboard 

600064865 

612  RAM 

601002166 

Model  5310  Printer 

Dot  Matrix 

EPORTS/POR'K 

601006084 

A  *  indicates  that  the  device  is  supplied  with  a  base  3B2  system. 

The  conHgurations  tested  by  the  team  were:  a  382/600  with  a  Vcache  board,  two  4426  terminals, 
one  630  MTG  terminal,  one  floppy  diskette,  one  147M  byte  hard  disk  drive,  one  60M  byte  cartridge 
tape  drive,  and  two  EPorts  boards;  a  3B2/600  with  one  4426  terminal,  one  606  BCT  terminal,  one 
630  MTG  terminal,  one  floppy  diskette,  two  147M  byte  hard  disk  drives,  one  60M  byte  cartridge 
tape  drive,  two  EPorts  boards,  and  one  6310  printer;  and  a  3B2/600  with  one  4425  terminal,  one  630 
MTG  terminal,  one  floppy  diskette,  one  60M  byte  cartridge  tape  drive,  two  147M  byte  hard  disk 
drives,  one  HiPorts  board,  two  EPorts  boards,  and  one  6310  printer. 
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Append  B:  Svahiatcd  Software  CoBoponents 


Below  is  a  listing  of  the  software  components  of  System  V/MLS.  System  V  Release  3.1.1  is 
distributed  as  a  collection  of  software  packages  plus  a  set  of  c<m  utilities.  Thus  the  sedtware 
components  of  the  TCB  can  be  described  by  the  various  packages  which  can  be  installed  on  the 
system  without  invalidating  the  rating  of  the  system. 

•  ATAT  UNIX  System  V  Release  3.1.1  Operating  System  Utilities 

Allowable  additional  packages: 

1.  Enhanced  Ports 

2.  SCSI  Cartridge  Tape  Utilities 

3.  ASSIST 

4.  Windowing  Utilities 

6.  Graphics  Utilities 
d.  HELP  Utilities 

7.  System  Administration 

8.  Inter-process  Communication 

9.  Directmy  and  File  Management 

10.  Editing  Utilities 

11.  Line  Printer  Spooling  Utilities 

12.  Perfmmance  Measurements 

13.  SpeO  Utilities 

14.  Terminal  Filters 

15.  Terminal  Infmnation  Utilities 
19.  Usw  Environment  Utilities 

•  ATAT  System  V/MLS  Release  1.2.0 

•  ATAT  630/MLS  Release  1.2.0 

AQ  standard  System  V  Release  3.1.1  packages  should  be  installed  priw  to  the  installation  of  Sjrstem 
V/MLS.  This  ensures  that  the  trusted  versions  of  the  system  seftware  are  not  overwritten  when 
any  other  package  k  installed. 
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Appendix  C:  Trusted  Canqmting  Base  ConqKments 

The  following  is  s  list  of  the  elements  that  comprise  the  trusted  computing  base  for  System  V/MLS. 
This  list  contains: 

1.  directories, 

2.  data  files  and 

3.  programs  (shell  scripts  and  executable  binaries). 

The  programs  listed  below  are  of  two  types: 

•  those  programs  trusted  to  enfcuce  system  security  policy,  and 

•  those  programs  trusted  to  operate  correctly  when  they  are  executed 
by  a  system  administrator. 


/ 

/bck 

/bin 

/bin/ar 

/bin/basename 

/bin /cat 

/bin/chgrp 

/bin/chmod 

/bin/chown 

/bin/chpriv 

/bin/cp 

/bin/cpk> 

/bin/date 

/bin/dd 

/bin/df 


Trusted  Cocnputing  Base  Compoients 


the  root  directory 
the  /bck  directory 
the  /bin  directmy 

archive  and  library  mwtainer  for  portable  archives. 

deliver  last  component  ot  pathname 

concatenate  and  print  files 

change  group  fik 

change  mode  of  file 

change  awntx  of  file 

change  privilege  of  file 

copy  files 

copy  file  archives  in  and  out 
print  and  set  the  system  date 
copy  files 

report  number  of  fim  disk  blocks 
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Tnuted  Conqratlng  Base  Conq>onent8 


/bin/diff 

differential  file  comparator 

/bin/dirname 

deliver  directory  component  of  pathname 

/bin/du 

summarise  disk  usage 

/bin/echo 

echo  arguments 

/bin/ed 

text  editor 

/bin/epatty 

set  EPORT  specific  terminal  settings 

/bin/expr 

evaluate  arguments  as  an  expression 

/bin/fabe 

returns  a  false  value 

/bin /file 

determine  file  type 

/bin/find 

find  files 

/bin/grep 

search  a  fib  for  a  pattern 

/bin/iperm 

* 

remove  an  interprocess  communication  object 

/bin/ipcs 

repent  interprocess  communication  facilities  status 

/bin/kiU 

terminate  a  process 

/bin /labels 

print  security  labeb 

/bin /line 

read  a  line  finm  a  file 

/bin/ln 

link  a  file 

/bin/login 

log  into  the  system 

/bin /Is 

Ibt  contents  of  a  directory 

/bin/mail 

read  w  send  mail 

/bin/mkdir 

make  a  directory 

/bin/mv 

move  a  file 

/bin/newgrp 

change  current  group 
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/bin/nevrpriv 

/bin/nice 

/bin/nohup 

/bin/od 

/bin/passwd 

/bin/pdpll 

/bin/pr 

/bin/pfl 

/bin/pwd 

/bin/red 

/bin/rm 

/bin/rmail 

/bin/rmdir 

/bin/rsh 

/bin/sed 

/bin/setpgrp 

/bin/sh 

/bin/sleep 

/bin /sort 

/bin/stty 

/bin/su 

/bin/tum 

/bin/sync 


Trusted  Conq>nting  Base  C!omponents 

change  current  privilege 

run  a  command  at  a  different  priority 

run  a  command  immune  to  hangups  and  quits 

octal  dump  program 

change  login  password 

machine  identification  program 

print  a  file 

report  process  status 

report  working  directory  name 

restricted  text  editor 

remove  a  file 

handle  remote  mail 

remove  a  empty  directory 

restricted  shell 

stream  editor 

set  process  group 

shell,  command  interpreter 

suspend  execution  for  an  interval 

sort  and/or  merge  files 

set  terminal  options 

become  another  user 

print  checksum  and  block  count  of  a  file 

update  super  block 
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/bin/tail 

/bin/tee 

/bin/time 

/bin/touch 

/bin/tme 

/bin/tty 

/bin/a370 

/bin/u3b 

/bin/u3bl6 

/bin/a3b2 

/bm/a3b6 

/bin/uname 

/bin/vax 

/bin/wc 

/bin/who 

/bin /write 

/boot 

/boot/CONLOG 

/boot/DBP 

/boot/EPORTS 

/boot/GENTTY 

/boot/HDELOG 

/boot/IDISK 


Trnited  Conyuting  Baie  Coin|>onenU _ 

deliver  last  part  of  file 
pipe  fitting 
time  a  command 

update  access  and  modification  times  a  file 

returns  a  true  value 

get  the  name  of  a  terminal 

machine  identification  program 

machine  identification  program 

machine  identification  program 

machine  identification  program 

machine  identification  program 

print  name  current  UNIX  system 

machine  identification  program 

print  character,  wOTd  and  line  count 

report  who  is  currently  on  the  system 

write  to  another  user 

contains  boot  modules  to  build  OS 

console  logging  module 

process  dkipatcher 

eports  driver 

general  terminal  support 

hard  disk  ernu'  logging  module 

internal  disk  driver 
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/boot/IPC 

/boot/IUART 

/boot /KERNEL 

/boot/MAU 

/boot/MEM 

/boot/MLS 

/boot/MSG 

/boot/OSM 

/boot/PDI_ 

/boot/PIR 

/boot/PORTS 

/boot/PRF 

/boot/S5 

/boot/SAT 

/boot/SCSI 

/boot/SDOO 

/boot/SEM 

/boot/SHM 

/boot/STOl 

/boot/STUBS 

/boot/SXT 

/boot/VCACHE 

/boot/XT 
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inter-process  communication  support  module 

universal  async  receive  transmitter  driver 

general  ob  support  routines 

math  acceleration  unit  driver 

memory  pseudo  device 

system  security  policy  module 

message  queue  module 

operating  system  messages  module 

hard  disk  logger  support  module 

programmable  interrupt  request  handler 

ports  driver 

system  preformance  monitoring  module 

s5  filesystem  module 

security  audit  trail  module 

SCSI  support  module 

SCSI  hard  disk  driver 

semaphore  module 

shared  memory  module 

SCSI  tape  driver 

stubs  module 

shell  layering  module 

virtual  cache  module 


hardware  layers  module 
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/dev 

/dev/* 

/dgmon 

/dgn 

/dgn/.edt_8wapp 

/dgn/EPORTS 

/dgn/MAU 

/dgn/PORTS 

/dgn/SBD 

/dgn/SCSI 

/dgn/VOAOHE 

/dgn/X.EPORTS 

/dgn/X.MAU 

/dgn/X.PORTS 

/dgn/X.SBD 

/dgn/X.SC3SI 

/dgn/X.VCAOHE 

/dgn/edt_data 

/edt 

/edt/SCSI 

/edt/SCSI/edt_data 

/edt/SCSI/edtgen 

/etc 


Trusted  Coixq>uting  Base  Conq>oncnts 


the  /dev  directcny 

all  devices  and  sub-directories  found  in  /dev 

diagnostic  monitor  program 

diagnostic  test  directory 

diagnostic  temp<x‘ary  file 

EPORTS  diagnostic  tests 

math  acceleration  unit  diagnostic  tests 

PORTS  diagnostic  tests 

system  board  diagnostic  tests 

SCSI  diagnostic  tests 

virtual  cache  diagnostic  tests 

additional  diagnostic  tests 

additional  diagnostic  tests 

additional  diagnostic  tests 

additional  di^nostk  tests 

additional  diagnostic  tests 

additional  diagnostic  tests 

equipped  device  table  data 

equipped  device  table  directory 

SCSI  equipped  device  table  direct(»7 

equ4>ped  devke  table  data  fn-  SCSI 

equipped  device  table  generator  fOT  SCSI 

the  /etc  directOTy 
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/etc/TIMEZONE 

/etc/bcheckrc 

/etc/brc 

/etc/bupsched 

/etc/bsapunbc 

/etc/checkliat 

/etc/chroot 

/etc/ckauto 

/etc/ckbupacd 

/etc/chi 

/etc/conslog 

/ctc/coredirs 

/etc/craah 

/etc/cron 

/etc/dcopy 

/etc/devnm 

/etc/dfeck 

/etc /diskeUeparm 

/etc/disks 

/etc/drvinstall 

/etc/editsa 

/etc/edittbl 

/etc/errcraah 


Trusted  Conqratfaig  Base  ConqMnients 


timeione  environment  variable  value 

system  initialisation  procedure 

system  initialisation  procedure 

print  time  for  backup  schedule  reminder 

force  self-configuration  bootstrap 

list  of  filesystems  processed  by  fsck 

change  root  directory  for  a  command 

determine  if  system  was  reconfigured  at  boot  time 

check  filesystem  backup  schedule 

clear  an  inode 

log  console  activity 

list  of  cm-e  directories 

examine  system  core  images 

clock  daemon 

copy  filesystem  for  optimal  access  time 

print  device  name 

check  two  filesystems  concurrently 

parameters  fm*  filesystems  made  on  diskettes 

add  device  entries  for  hard  disks  in  equipped  device  table 

install/uninstall  a  driver 

add  or  delete  entries  from  software  application  file 
edit  equipped  device  table 
move  kernel  error  log  to  save  file 
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/etc/errdump 

/etc/errint 

/etc/expresa 

/etc/ff 

/etc/finc 

/etc/lltboot 

/etc/fmtflop 

/etc/fmthard 

/etc/format 

/etc/frec 

/etc/fsck 

/etc/f8ck512 

/etc/fsdb 

/etc/f8db512 

/etc/fsstat 

/etc/fstab 

/etc/fetyp 

/etc/fstyp.d 

/  etc  /fstyp.d  /sSfatyp 

/etc/fu8er 

/etc/getmajor 

/etc/getty 

/etc/gettydefs 


Trusted  Coiiq>utmg  Base  C<niiponents 


print  kernel  error  log 

extract  error  log  information  at  specified  interval 

enable  or  disable  system  diagnostics 

list  file  names  and  statistics  for  a  Hlesystem 

fast  incremental  backup 

set  NVRAM  parameters  for  boot 

format  diskettes 

format  hard  disks 

front  end  to  fmthard  and  fmtflop 

fast  recovery  of  files  by  inode  numbers  from  a  tape 

check  and  repair  filesystems 

check  and  repair  filesystems  (old  version) 

filesystem  debugger 

filesystem  debugger  old  version 

report  filesystem  status 

list  of  automatically  mounted  filesystems 

determine  filesystem  identifier 

filesystem  type  directory 

s5  filesystem  identification 

identify  processes  using  a  file 

determine  major  number  of  hardware  devices 

set  up  terminal  fm*  login 

used  by  getty  to  set  up  terminal  connections 
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Trusted  Cknuputing  Base  ComponentB 


/etc/gettype 

/etc/group 

/etc/grpck 

/etc/hdeadd 

/etc/hdefix 

/etc/hdelogger 

/etc/helpadm 

/etc/init 

/etc/init.d 

/etc/init-d/ANNOUNCE 

/etc/mit.d/MOUNTFSYS 

/etc/init.d/PRESERVE 

/etc/init. d/README 

/etc/mit.d/RMTMPFILES 

/etc/init.d/sutoconfig 

/etc/init.d/cron 

/etc /init  .d  / disks 

/etc/init.d/firstcheck 

/etc/init.d/perf 

/etc/init.d/scsi 

/etc/init.d/sysetup 

/etc/inittab 

/etc/instaO 


get  device  and  bus  name 
sanitise  group  file 
check  the  group  file 
add  or  delete  hdelog  reports 
report  <»-  change  bad  block  mapping 
hard  disk  error  log  daemon 
make  changes  to  the  halp  database 
process  control  initialisation 
system  initialisation  script  directory 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  script 
system  initialisation  table 
install  command 
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/etc /ioctLsyscon 

/etc/killall 

/etc/labelit 

/etc/ldsysdump 

/etc/link 

/etc/log 

/  etc  /log/filesave.log 
/etc/magic 
/etc/maater.d 
/etc/master.d/conlog 
/etc /master  .d  /diap 
/etc/master  .d/eports 
/etc/maater.d  /  gentty 
/etc/maater.d/hdelog 
/etc  /  master  .d/idisk 
/etc/master  .d/ipc 
/  etc/  master  .d/iuart 
/  etc  /  master.d/kemel 
/etc/master  .d/mau 
/etc/master  .d/mem 
/etc/master.d/mb 
/etc/master  .d/msg 
/  etc/  master  .d/  osm 


Trusted  Confuting  Base  Components 

console  terminal  setting 

kill  all  active  processes 

label  a  filesystem 

load  system  dump  from  diskettes 

link  files  or  directories 

volcopy  log  directory 

log  file  for  volcopy  command 

list  of  magic  numbers  nsed  by  the  file  command 

directory  of  device  driver  master  files 

console  log  master  file 

dispatcher  master  file 

eports  master  file 

general  tty  master  file 

hard  disk  error  logger  master  file 

internal  disk  master  file 

inter-process  communication  master  file 

universal  async  receive  transmitter  master  file 

general  os  master  file 

math  acceleration  unit  master  file 

memory  master  file 

security  policy  master  file 

message  queue  master  file 


08  message  master  file 
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/etc/  master.d /pdi_ 

/etc/master.d/pir 

/etc /master  .d/pcsis 

/etc/master. d/prf 

/etc  /  master.d /s6 

/etc/master  .d/sat 

/etc/master.d/scsi 

/etc /master.d  /sdOO 

/etc/master  .d/sem 

/etc/master.d/shm 

/etc /master  .d /stOl 

/etc/master.d/stubs 

/etc/master  .d/sxt 

/  etc  /master.d /vcache 

/etc/master.d/xt 

/etc/mkboot 

/etc/mkfi 

/etc/mJraod 

/etc/mkunix 

/etc/mnttab 

/etc/motd 

/etc/mount 

/etc/mountaO 
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hdelogger  support  master  file 
programmable  interrupt  master  file 
PORTS  master  file 
system  profiler  master  file 
sS  master  file 

security  audit  trail  master  file 

SCSI  master  file 

SCSI  hard  disk  master  file 

semaphore  master  file 

shared  memory  master  file 

SCSI  tape  driver  master  file 

stubs  master  file 

shell  layering  master  file 

virtual  cache  master  file 

hardware  layering  master  file 

make  a  bootable  object  file 

construct  a  fiksystem 

create  a  block  or  character  special  file 

make  a  bootable  system  file 

list  of  currently  mounted  filesystems 

message  of  the  day  file 

mount  a  filesystem 

mount  all  filesystems  found  in  /etc/fstab 
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/etc/mvdir 

/etc/ncheck 

/etc/newboot 

/etc/pasawd 

/etc/porta 

/etc/prfdc 

/etc/prfld 

/etc/pr^r 

/etc/prfanap 

/etc/prfatat 

/etc/proGl« 

/etc/prtconf 

/etc/prtconf.d 

/etc/prtconf.d/acai 

/etc/prtvtoc 

/etc/pump 

/etc/pwck 

/etc/rc.d 

/etc/rc.d/lp 

/etc/rc.d/aatup 

/ete/rcO 

/etc/rcO.d 

/etc/rc0.d/K00ANNOUNCE 


move  a  directory 

generate  pathnamea  from  inode  nnmbera 

load  boot  programa  onto  the  diak  boot  partition 

aanitiaed  paaaword  file 

aetup  PORTS  card 

ayatem  profiler 

ayatem  profiler 

ayatem  profiler 

ayatem  profiler 

ayatem  profiler 

ayatem  pn^e 

print  ayatem  configuration 

directory  of  aupport  rontinea  for  /etc/prtconf 

print  SCSI  configuration 

print  the  VTOO  of  a  device 

download  pump  code  to  a  peripheral  device 

check  paaaword  file 

ayatem  initialisation  directory 

ayatem  initialiiation  acript 

ayatem  initialiaation  acript 

ayatem  initialiiation  acript 

ayatem  initialiiation  directory 

ayatem  initialiiation  acript 
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/etc  /rcO.d /KOBeatstop 
/etc/rcO.d /KTOcron 
/etc/rc2 
/etc/rc2.d 

/etc/rc2.d/K0B8at8top 

/etc/rc2.d /SOOfintcheck 

/etc/rc2.d/S008csi 

/etc/rc2.d/S01MOUNTFSYS 

/etc/rc2.d/S02PRESERVE 

/etc/rc2.d/S06RMTMPFILES 

/etc/rc2.d/S06aatetart 

/etc/rc2.d/S07]n]s8tart 

/etc/rc2.d/S10disks 

/  etc  /rc2.d/S  ISsatoconfig 

/etc/rc2.d/S20By8etap 

/etc/rc2.d/S21perf 

/etc/rc2.d/S76cron 

/etc/rc2.d/S80err8tart 

/etc/rc3 

/etc/rmha 

/etc/eave.d 

/etc/save.d/except 

/etc/savecpio 


ayatem  initialiiation  acript 

ayatem  initialisation  acript 

ayatem  initialisation  acript 

ayatem  initialisation  directory 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

ayatem  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  initialisation  script 

system  mitialisation  script 

remove  SCSI  boat  ad^ter 

save  directory  used  by  /etc/savecpio 

list  of  exception  file  nsed  by 

save  filesystems  in  cpio  format  on  removable  media 
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/etc /scsi/compress 

/etc  /scsi /compress. d 

/etc/scsi/compress  .d /qt  ape 

/  etc/scsi/edittbl 

/etc/scsi/mkdev 

/etc/setclk 

/etc/setmnt 

/etc/shutdown 

/etc/shatdown.d 

/etc/stdprofile 

/etc/swap 

/etc/sysdef 

/etc/system 

/etc/telinit 

/etc/uadmin 

/etc/umount 

/etc/umountall 

/etc/unlink 

/etc/utmp 

/etc/volcopy 

/etc/vtoc 

/etc/wall 

/etc/whodo 


compress  a  SCSI  filesystem 

support  directory  for  compression  of  a  filesystem 

use  SCSI  tape  when  doing  a  compression  of  the  filesystem 

edit  SCSI  device  table 

make  SCSI  /dev  entries 

set  system  clock 

modify  /etc/mnttab  file 

change  system  init  state 

support  directory  for  shutdown  command 

default  .profile  for  newly  created  users 

swap  administrative  interface 

print  system  tunables 

defines  which  drivers  and  modules  are  included  in  the  OS 
process  control  initialisation 
administrative  control  conunand 
umount  a  filesystem 

amount  all  Hlesystem  found  in  /etc/fetab 

unlink  a  file  or  directory 

system  accounting  information 

make  literal  copy  of  filesystem 

the  vtoc  directory 

write  to  all  users  on  the  system 

print  system  activity 


C-14 


/etc/wtmp 

/filledt 

/install 

/Ub 

/lib/lboot 

/lib/libp 

/lib/mboot 

/lib/olboot 

/lib/pump 

/lib/pnmp/eports 

/Ub/ pump/ports 

/lib/puinp/pOTt8.hpp 

/lib/pump/scsi 

/mis 

/mb/.mkgrp 

/mls/.inkussr 

/mb/bin 

/mb/bin /LpSetnp 
/mb/bin /MailSetup 
/mb/bin /Permsetnp 
/mb/bin/SscadmSstnp 
/mb/bin/UncpSetnp 
/mb/bin/group.ckanap 
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system  accounting  information 
file  equipped  device  table 
install  directory 
library  directory 
system  boot  program 
libp  library  directory 
system  boot  program 
system  boot  program 
system  pump  code  directory 
pump  code  for  EPOBTS 
pump  code  for  PORTS 
pump  code  for  HIPORTS 
pump  code  for  SCSI 
the  /mb  directory 
last  group  identifier  used 
last  user  identifier  used 
the  /mb/bin  directmy 
Ip  setup  procedure 
mail  setup  procedure 

establbh  known  permission  on  critical  files/directories 
secadm  setup  procedure 
UUCP  setup  procedure 
ckanup  group  file 
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/mls/bin /mkdevcir 

/mk/bin/mklbl 

/mls/bin /mlsst  art 

/mls/bin/prlbl 

/mls/bin/rmdevclr 

/  mls/bin/aatfmt 

/  mls/bin/satmap 

/mis /bin /satsave 

/mls/bin /satst  art 

/mls/bin/satstop 

/mis  /bin  /sessions 

/mls/bin/sfsmap 

/mls/bin/updatepwgr 

/mls/categories 

/mls/clearances 

/mls/cleardev 

/mls/group 

/mls/h_iab«is 

/mis/labeb 

/mb /levels 

/mb/passwd 

/mb/sessions 

/mnt 


Trusted  Computing  Base  Components 

make  device  cbarance  entries 

make  a  labeb  Gle 

system  initialbation  script 

print  in  readable  form  the  labeb  file 

remove  a  device  clearance  entry 

format  the  security  audit  trail 

create  the  preamble  of  the  security  audit  trail 

collect  audit  information  from  the  kernel 

system  initialbation  script 

system  initialbation  script 

print  current  sessions  information 

filesystem  map  for  audit  trail 

maintain  sanitbed  password  and  group  files 

system  deHned  categories 

deHnition  of  users  clearances 

definition  of  device  clearances 

real  group  file 

human  readable  form  of  labeb  file 
definitions  of  all  privileges  on  system 
system  defuied  bveb 
real  password  Hb 

directory  of  sessions  on  the  system 
the  /mnt  directory 


c-ie 


Final  Evaluation  Report  ATJtT  System  V/NL8 
Trusted  Computing  Base  Components 
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/save 

/shlib 

/8hlib/libc_8 

/tmp 

/unix 

/u8r 

/usr/adm 

/u8r/adm/bin 

/u8r/adin /bin /mvlog 

/usr/adm/eirlog 

/u8r/adm/8uIog 

/u8r/admin 

/u8r/admin/.gettyvaluesl9 

/u8r/ admin /.profile 

/ner/admin/bupeched 

/usr/admin/checldsye 

/  usr/ admin/checkfeye.d 

/uer/admin/checkfsya.d  /  diekette 

/  usr/ admin  /  gettyvaiues 

/u8r/admin  /  makefeys 

/uar/admin/makefeys.d 

/usr /admin  /  makefisye.d  /diskette 

/nsr/admin/menn 


the  /save  directory 
the  shared  library  directory 
the  C  shared  library 
the  /tmp  directory 

the  disk  image  of  the  operating  system 
the  /usr  directory 

the  administrative  information  directory 

an  administrative  command  directory 

move  log  files 

an  error  log  file 

Bu  activity  log  file 

simplified  administration  directory 

terminal  settings  for  use  of  simplified  administration 

profile  for  simplified  administration 

simplified  administration  script 

simplified  administration  script 

support  directory  for  checkfsys 

simplified  administration  script 

simplified  administration  script 

simplified  administration  script 

support  directory  for  makefsys 

simplified  administration  script 

simplified  administration  menu  directory 
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/  usr/admin /menu /DESO 
/usr/admin  /  menu  /  diagnostics 


simplified  administration  script 


simplified  administration  directmy 
/usr/admin  /  menu  /  diagnostics /DESC 

simplified  administration  script 
/  usr/  admin /menn/diagnostics  /diskrepair 

simplified  administration  script 
/  usr/admin  /  menu  /  diagnostics  / diskreport 

simplified  administration  script 

/usr/ admin /menu /diskmgmt 


simplified  administration  directory 

/  usr/admin  /menu  /diskmgmt /DESC 

simplified  administration  script 
/usr/  admin /menu /diskmgmt  /checkfisys 

simplified  administration  script 
/usr/admin/menu/diskmgmt/checkfsys.d 

support  directory  for  checkfsys 
/  usr/ admin  /menu /diskmgmt  /checkfsys.d  /diskette 

simplified  administration  script 

/usr/ admin/ menu/diskmgmt/cpdisk 

simplified  administration  script 
/usr/ admin/menu/  diskmgmt  /  cpdisk.d 

support  directory  for  cpdisk 
/  usr/ admin  /  menu  /diskmgmt  /cpdisk.d  /diskette 

simplified  administration  script 

/usr/admin  /  menu  /diskmgmt /erase 


simplified  adminbtration  script 

/usr/ admin  /  menu  /  diskmgmt /erase.d 


support  directory  for  erase 
/  usr/admin /menu/diskmgmt/erase.d  /  diskette 

simplified  administration  script 

/  usr/admin  /menu  /  diskmgmt  /format 

simplified  administration  script 
/usr/admin/menn/diskmgmt/format.d 

support  directory  for  format 
/usr/ admin /menu/diskmgmt/format  .d  /diskette 

simplified  administration  script 
/  usr/ admin /menu  /diskmgmt /harddisk 

simplified  administration  directory 
/nsr/admin/menn/diskmgmt/hardduk/DESC 

simplified  administration  script 
/  usr/  admin /menu/diskmgmt /harddisk/display 

simplified  administration  script 
/usr/admin/menu/diskmgmt/harddisk/display.d 

support  directory  for  display 


C-18 


Final  Evaluation  Report  ATKT  System  V/MLS 
Trusted  Computing  Base  Components 
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/  nsr/admin  /  menu /diskmgmt  /harddisk/display  .d/disk 

simplified  administration  script 
/  usr/ admin  /  menu  /  diskmgmt  /harddisk /format 

simplified  administration  script 
/usr/ admin  /  menu  /diskmgmt  /harddisk /format  .d 

support  directory  for  format 
/usr/admin/menu/diskmgmt/harddisk/format.d/disk 

simplified  administration  script 
/usr/ admin  / menu  /diskmgmt /harddisk  /makehdfsys 

simplified  administration  script 
/usr/admin/menu/diskmgmt /harddisk/partitioning 

simplified  administration  script 
/usr/  admin/  menu  /diskmgmt /harddisk /partitioning.d 

support  directory  for  partitioning 
/usr/admin/menu/diskmgmt/harddisk/partitioning.d/disk 

simplified  administration  script 
/  usr/admin /menu  /diskmgmt /harddisk /rmdisk 

simplified  administration  script 
/usr/admin/menu/diskmgmt/harddisk/rmdisk.d 

support  directory  for  rmdisk 
/usr/admin/menu  /diskmgmt /harddisk  /rmdisk.d/disk 

simplified  administration  script 
/usr/ admin  /  menu  /  diskmgmt  /makefsys 

simplified  administration  script 
/usr/admm /menu/diskmgmt  /  makefsys.d 

support  directory  for  makefsys 
/usr/ admin  /menu/diskmgmt  /makefsys.d  /diskette 

simplified  administration  script 
/usr/admin /menu  /diskmgmt  /mountfsys 

simplified  administration  script 
/usr/ admin /menu  / diskmgmt /mountfsys  .d 

support  directory  for  mountfsys 
/  usr/  admin  /menu  /diskmgmt/mountfsys.d/diskette 

simplified  administration  script 
/usr/ admin/  menu  /diskmgmt/umountfsys 

simplified  administration  script 
/usr/admin/menu/diskmgmt  /umountfsys.d 


support  directory  for  umountfsys 
/  usr/ admin  /  menu/diskmgmt  /  umountfsys.d /diskette 

simplified  administration  script 

/usr/ admin /menu/filemgmt 

simplified  administration  directory 

/  usr/ admin/menu/filemgmt /DEISC 

simplified  administration  script 

/usr  /  admin  /  menu /filemgmt /backup 

simplified  administration  script 
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/usr/admm/menu/filemgmt/backap.d 

sapport  directcHy  for  backup 
/aar/admin /menu/fikingmt  /backap.d/9track 

simplified  administration  script 
/usr/admin  /menu/filemgmt/backup.d/ diskette 

simplified  administration  script 
/usr/admin/mena/filemgmt/backup.d/qtape 

simplified  administration  script 
/usr/admin/menu/filemgmt/bupsclied 

simplified  administration  directory 
/usr/admin/menu/filemgmt/bupsched/DESC 

simplified  administration  script 
/usr/admin /menu  /filemgmt  /bupsched /schedcheck 

simplified  administration  script 
/nsr/admin/menu/filemgmt/bupsched/schedmsg 

simplified  administration  script 

/usr/admin /menu/filemgmt/diskuse 

simplified  administration  script 

/  usr/  admin/menu/filemgmt/fileage 

simplified  administration  script 

/usr/admin/menu/filemgmt/filesise 

simplified  administration  script 
/usr/admin/menu/filemgmt/lisbackup 

simplified  administration  script 
/usr/admin/menu/filemgmt/hsbackup.d 

support  directory  for  hsbackup 
/u8r/admin/menu/fi]emgmt/hsbackup.d/9track 

simplified  administration  script 
/usr/admin/menu/filemgmt/hsbackup.d/disk 

simplified  administration  script 
/nsr/admin/menu/filemgmt/hsbacknp.d/qtape 

simplified  administration  script 
/usr/admin/menu/filemgmt/hsrestore 

simplified  administration  script 
/nsr/admin/menu/filemgmt/hsrestore.d 

support  directory  fnr  hsbackup 
/usr/admin/menu/filemgmt/hsrestore.d/Qtrack 

simplified  administration  script 
/usr/admin  /menu/filemgmt/hsrestcn^.d/ disk 

simplified  administration  script 
/usr/admin/menu/filemgmt/hsrestore.d/qtape 

simplified  adminktratioa  script 


/usr/admin/menu/filemgmt/re8t<we 

simplified  administration  script 
/usr/admin  /menu  /fikmgmt/restore.d 

support  directory  fOT  restore 
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/usr/admin/mena/fikmgmt/refltore.d/Qtradc 

simplified  adminisiration  script 
/asr/adinin/mena/filemgmt/restore.d/diskette 

simplified  administration  script 
/asr/adinin/mena/filemgmt/restore.d/qtape 

simplified  administration  script 

/usr/admin/mena/filemgmt/store 

simplified  administration  script 

/usr/admin/menu/filemgmt/store.d 

suppmt  directory  for  store 
/ttsr/admin/mena/filemgmt/st<m.d/9track 

simplified  administration  script 
/usr/admin/mena/filemgmt/store.d/diskette 

simplified  administration  script 
/nsr/admin/mena/filemgmt/store.d/qtape 

simplified  administration  script 

/nsr/admin/menu/machinemgmt 

simplified  administration  directory 
/usr/admin/menu/macliinemgmt/DESO 

simplified  administration  script 
/nsr/admin/mena/machinemgmt/aatold 

simplified  administration  script 
/usr/admin/mena/machinemgmt/firmware 

simplified  administration  script 
/  usr/admin  /menu  / machinemgmt  /floppykey 

simplified  administration  script 
/usr/  admin  /  menu/machinemgmt  /powerdown 

simplified  administration  script 
/asr/admin/mena/machinemgmt/reboot 

simplified  administration  script 
/usr/  admin  / menu/  machinemgmt /whoeon 

simplified  administration  script 

/ usr/  admin /menu  / packagemgmt 

simplified  administration  directmy 
/  usr/admin  /  menu  /packagemgmt /DESG 

simplified  administration  script 

/  usr/admin  /menu/s<rflwaremgmt 

simplified  administration  directcay 
/usr/admin  /menu/sc^waremgmt  /DE}SC 

simplified  administration  script 
/usr/admin/menu/softwaremgmt/instali 

simplified  administration  script 
/usr/  admin  / menu  / s<^waremgmt /installpkg 

simplified  administration  script 
/  usr/admin/menu  /softwaremgmt/installpkg.d 

support  directory  for  installpkg 
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/  usr/admin /menu /softwaremgmt /installpkg.d/diskette 

simplified  administration  script 
/usr/admin/menn  /  softwaremgmt /listpkg 

simplified  administration  script 
/  usr/admin/menn  /  softwaremgmt  /removepkg 

simplified  administration  script 
/usr/admin  /  menu  /  softwaremgmt  /removepkg.d 

support  directory  for  removepkg 
/  usr/ admin/menu /softwaremgmt /removepkg.d  /diskette 

simplified  administration  script 
/usr/ admin/menu  /softwaremgmt/runpkg 

simplified  administration  script 
/  usr/ admin /menu  /softwaremgmt  /runpkg.d 

support  directory  for  runpkg 
/usr/ admin/menu/  softwaremgmt  /runpkg.d  /diskette 

simplified  administration  script 
/  usr/admin /menu/softwaremgmt /tapepkg 

simplified  administration  script 
/usr/admin /menu  /softwaremgmt /uninstall 

simplified  administration  script 

/ usr  / admin  /menu  / sy  ssetup 

simplified  administration  directory 

/  usr/ admin /menu/syssetup /DESC 

simplified  administration  script 
/usr/ admin/menu/syssetup/ admpasswd 

simplified  administration  script 
/usr/admin/menu/syssetup/datetime 

simplified  administration  script 
/usr/admin  /  menu  /syssetup/nodename 

simplified  administration  script 

/  usr/ admin/ menu  /  syssetup  /setup 

simplified  administration  script 
/usr/admin  /  menu  /syssetup  /syspasswd 

simplified  administration  script 

/  usr/ admin/menu  /  tapemgmt 

simplified  administration  directory 

/usr/admin/menu/tapemgmt/DESC 

simplified  administration  script 
/  usr/admip  /menu  /  tapemgmt /compress 

simplified  administration  script 
/  usr/admin  /  menu/ tapemgmt  /compress.d 

support  directory  for  compress 
/usr/admin/menu/tapemgmt/compress.d/qtape 

simplified  administration  script 

/usr/admin/menu  /  tapemgmt  /lonaak 


simplified  administration  script 
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/usr/admin/menu  /  tapemgmt /info 

simplified  administration  script 
/usr/admin/menu/tapemgmt/resetosage 

simplified  administration  script 
/usr/admin/menu/ tapemgmt /rmtape 

simplified  administration  script 
/  usr /admin /menu  /  tapemgmt  /rmt  ape.d 

support  directory  for  rmtape 
/usr/admin /menu /tapemgmt  /rmtape.d/9track 

simplified  administration  script 
/usr/  admin  /menu /tapemgmt  / rmtape.d/qt  ape 

simplified  administration  script 

/usr/admin/menu/ttymgmt 

simplified  administration  directory 

/usr/admin  /menu  /  ttymgmt/DESC 

simplified  administration  script 

/usr /admin /menu  / 1  tymgmt  /lineset 

simplified  administration  script 
/usr/admin /menu /ttymgmt  /  mklineset 

simplified  administration  script 

/usr/admin/menu/ttymgmt/modtty 

simplified  administration  script 

/usr/admin  /  menu/uaermgmt 

simplified  administration  directory 

/  usr/admin  /  menu/usermgmt/DESO 

simplified  administration  script 
/usr/admin/menu  /  usermgmt/ addgroup 

simplified  administration  script 
/usr/admin  /menu  /usermgmt/ adduser 

simplified  administration  script 
/usr/admin/menn/usermgmt/delgroup 

simplified  administration  script 
/usr/admin  /menu/usermgmt/deluser 

simplified  administration  script 
/usr/admin/menu/usermgmt/lsgroup 

simplified  administration  script 

/usr /admin/menu/usermgmt /isuser 

simplified  administration  script 
/nsr/admin/menu/nsermgmt/modadduser 

simplified  administration  script 
/usr/admin/menu/ usermgmt /modgroup 

simplified  administration  directmy 
/usr /admin /menu /usermgmt  /  modgroup/DESC 

simplified  administration  script 
/usr/admin  /menu /usermgmt/  modgroup/chgname 

simplified  administration  script 
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/usr /admin  /menu/usermgmt/  moduser 

simplified  administration  directmy 
/  nsr/admin  /menn/usermgmt  /  moduser/DESC 

simplified  administration  script 
/nsr/admin/menu/usermgmt/modnser/cligloginid 

simplified  administration  script 
/usr /admin  /  menu  /  usermgmt /moduser/  chgpasswd 

simplified  administration  script 
/usr  /  admin  /menu/ usermgmt  /  moduser/chgshell 

simplified  administration  script 


/usr /admin  /mountfsys 

/usr/admin/mountf8y8.d 

/usr /admin  /mountfsys.d  /  diskette 

/  usr/admin  /powerdown 

/usr/admin/profile.dot 

/usr/admin/setup 

/usr/admin/sysadm 

/usr/admin  /umountfoys 

/usr/admin/umountfeys.d 

/usr/admin/ umountfeys.d/diskette 

/usr/admin/unixadmin 

/usr/bin 

/usr/bin/d30init 

/usr/bin/PFload 

/usr/bin/addgrp 

/usr/bin  /  addpriv 

/usr/bin/adduser 

/usr/bin/at 


simplified  administration  script 
support  directory  for  mountfeys 
simplified  administration  script 
simplified  administration  script 
simplified  administration  script 
simplified  administration  script 
simplified  administration  script 
simplified  administration  script 
support  directory  for  umountfsys 
simplified  administration  script 
simplified  administration  script 
the  /usr/bin  directory 
630  initialisation  program 

load  programmable  function  keys  feu-  a  630  terminal 

add  members  to  a  group 

add  members  to  a  privilege 

add  a  user  to  the  system 

run  a  task  at  a  specified  time 
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/usr/bin/batch 

/usr/bin/cancel 

/usr/bin /checkfsys 

/usr/bin/clearances 

/usr/bin/crontab 

/usr/bin/cut 

/uar/bin/delgrp 

/uw/bin/delpriv 

/usr/bin /deluser 

/usr/bin/dissbie 

/usr/bin/dmdM 

/usr/bin/dominates 

/usr/bin/dsconfig 

/usr/bin/enable 

/nsr/bin/getopt 

/usr/bin/id 

/usr/bin/layers 

/usr/bin/lp 

/usr/bin/lpstat 

/usr/bin/Isgrp 

/usr/bin/bprhr 

/usr/bin/maikheck 

/usr/bin/maibc 
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run  a  task  at  a  specified  time 
cancel  an  print  request 
simplified  administration  script 
print  user  or  session  clearances 
add  or  delete  tasks  to  users  crontab  file 
cut  a  field  from  the  input 
delete  members  from  a  group 
delete  members  from  a  privilege 
delete  a  user  from  the  system 
disable  a  printer 

download  a  program  into  the  630  terminal 
determine  dominate  relationship  between  labels 
display  name  and  description  of  device 
enable  a  printer 
parse  options 

print  user  and  group  identifiers  and  names 

630  window  manager 

send  a  print  request 

print  Ip  status 

list  group  infmmation 

list  privilege  information 

check  for  and/or  fnward  multilevel  mail 

interactive  electronic  mail  processing  system 
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/usr/bin/makefsys 

/  usr/bin  /  maxckar 

/  usr/bin /mkdevcfr 

/usr/bm/mkgrp 

/  usr/bin  /mkpriv 

/usr/bin/ mkussr 

/usr/bin/modgrp 

/usr/bin/modpriv 

/  usr/bin/mountfsys 

/usr  /bin/ mvpriv 

/usr/bin/pack 

/usr/bin/pcat 

/usr/bin/pg 

/usr/bin/powerdown 

/usr/bin  /midevclr 

/usr/bin/ringrp 

/usr/bin/rmpriv 

/usr/bin/rmnser 

/usr/bin/sadp 

/usr /bin/sag 

/usr/bin/sar 

/usr/bin/sdifF 

/uM'/bin/setup 
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simplified  administration  script 

establish  a  users  clearance 

make  device  clearance  entries 

make  a  new  group 

make  a  new  privilege 

make  a  new  entry  in  the  password  file 

change  owner  cS  a  group 

change  name  ctf  a  privilege 

simplified  administration  script 

move  a  file 

compress  a  file 

print  a  compress  file  after  expansion 
file  perusal  filter  for  terminals 
simplified  administration  script 
remove  device  clearance  entries 
remove  a  group 
remove  a  privilege 

remove  an  entry  in  the  password  file 

disk  access  prcrfiler 

graph  system  activity 

rep<nrt  system  activity 

side  by  side  difference  comparatm- 

simplified  administration  script 
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/usr/bin/shl 

/asr/bin/sysadm 

/usr/bin/tabs 

/usr/bin/tic 

/usr/bin /timex 

/usr/bin/tput 

/u«r/bin/tr 

/usr  /bin /umountfiByB 

/usr/bin/ unpack 

/usr/bin/xtd 

/usr/bin/xts 

/usr/bin/xtt 

/usr/dmd 

/usr/dmd/bin 

/nsr/  dmd/bin/chk630 

/uar/dmd  /bin/fw.mods 

/usr/lbin 

/usr/lbin/ admerr 

/usr/lbin/agefile 

/nsr/lbin/aakx 

/usr/lbin  /checklist 

/usr/lbin/checkre 

/usr/lbin  / checkyn 
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shell  layer  manager 

simplified  administration  script 

set  tabs  on  a  terminal 

terminfo  compiler 

time  a  command 

query  terminfo  database 

translate  characters 

simplified  administration  script 

uncompress  a  packed  file 

gather  xt  statistics 

gather  xt  statistics 

gather  xt  statistics 

630  software  directory 

trusted  630  downloadable  software 

check  630  firmware 

630  firmware  modifications 

the  /usr/lbin  directory 

issue  a  error  message  for  an  administrative  command 

age  files  by  moving  to  older  and  older  names 

prompt  with  a  question 

get  an  answ«-  that  is  one  from  a  list 

check  an  answer  against  a  series  ci  regular  expression 

get  a  yes/no  response  from  a  user  or  check  answer  to  question 
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/usr/lbin/chkyn 

/  usr/lbin  /  devinfo 

/usr/lbin/duklabel 

/usr  /Ibin  /diskumount 

/usr/lbin/drivename 

/uflr/lbin/fdate 

/usr/lbin/filecheck 

/uar/lbin/fsinfo 

/uar/lbin/getedt 

/uar/lbin/ignore 

/uar  /Ibin/labclfeiiaine 

/uar/lbin/largeat 

/uar/lbin/lightenfa 

/aar/lbin/mkloet+found 

/  uar/lbin /mkmenaa 

/  uar /Ibin  /  mktable 

/uar/lbin/ncpio 

/uar/lbin/num 

/uar/lbin/oldfik 

/uar/lbin/optparttn 

/uar /Ibin/readpkg 

/uar /Ibin  /  reatorefilea 

/uar/lbin/rmjunk 
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get  a  yes/no  response  from  a  user  or  check  answer  to  question 
return  information  about  a  storage  device 
print  the  label  of  a  diskette 

perform  a  umount  and  complain  if  it  does  not  work 

derive  a  device  name  from  its  pathname 

print  file  modification,  creation  or  access  date/time 

check  for  files  added  and  deleted  below  the  given  directory 

print  filesystem  information 

get  external  device  table 

no  op  command 

return  filesystem  name  and  volume  label  as  shell  variable  assignments 
find  largest  files  under  a  given  directory 
routine  to  clean  up  filesystems 
make  a  lost  and  found  directory 

descend  a  tree  directory  looking  for  menus  of  commands 
concatenate  files,  stripping  comments  and  empty  lines 
modified  cpio 

check  for  all  numeric  arguments 
look  for  files  older  than  a  specified  number  of  days 
allocate  any  disk  free  space  into  user  partitions 
read  packages  from  the  tape 

restmv  a  file  from  the  save  area  to  the  regular  filesystems 
remove  filn  of  dubious  WOTth 
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/ttsr/lbin/nnkdir 

/asr/lbm/rrmdir 

/usr/lbin/sunedev 

/  asr/lbin  /selectdevice 

/asr/lbin/Mlpattern 

/nsr/lbin/skip 

/usr/lbin  /tpacewatch 

/uar/lbin/spclfliie 

/usr/lbin  /  vnik£i 

/usr/lib 

/usr/lib/.OOREterm 

/u8r/lib/.COREt«nn/4/4425 

/u8r/bb/.COREt«mi/A/ATT442« 

/a8r/lib/.COREtenn/a/att4428 

/usr/lib/accept 

/asr/Ub/cron 

/uir/lib/cron/.proto 

/usr/lib/cron/at.aUow 

/nsr/lib/cron/cron.allow 

/usr/lib/cixm/log 

/usr/lib/croa/queuedefii 

/un’/lib/lpadmin 

/usr/lib/lpmoYe 


recursivsly  make  directories 
recursively  remove  directories 

determine  if  device  files  refer  to  the  same  actual  device 

select  SA  name  fOT  a  device 

select  which  pattern  matches  a  given  device  file 

skip  a  package  on  t^>e 

look  at  filesystem  space. 

determine  the  sue  of  a  special  file 

make  a  filesystem  within  a  hard  disk  partition 

the  /usr/lib  directmy 

core  terminal  definitions  directcny 

terminal  definition  fw  4425 

terminal  definition  for  4425 

terminal  definition  for  4425 

allow  a  printer  to  accept  requests 

the  cron  directwy 

default  initial  script  for  cron  jobs 

file  of  users  authorised  to  use  the  at/batch  command 

file  of  users  authorised  to  use  the  cron  command 

log  of  cron  activities 

current  crcm  queue 

ip  administrative  interface 

move  a  print  request  to  another  printer 
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/usr/lib/lpsched 

/usr/lib/lpshut 

/usr/lib/maUx 

/usr  /lib/ maibc/ maibc.help 

/usr/lib/maUx/rnunail 

/u8r/lib/mv_dir 

/usr/Iib/pgmark 

/usr/lib/reject 

/uar/lib/aa 

/usr/Iib/sa/sal 

/u8r/lib/8a/«a2 

/  usr /lib/aa/aadc 

/usr/lib/scsi 

/  usr/Ub/scsi/fomiat 

/  usr/lib/scsi/hdeflx 

/  usr/Iib/scsi/labclfsname 

/  usr/lib/scsi/qiccopy 

/usr/lib/scsi/adOO.O 

/usr /lib/  scsi/selectscsi 

/  uar/lib/scai/tapecntl 

/  usr/lib/scsi/  tc.index 

/usr/lib/terminfo 

/usr/lib/ tenniiifo/4/ 4426 
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Ip  scheduler 
stop  Ip  scheduler 
maibc  directory 
mailx  help  file 

remove  empty  mail  files  from  mail  directory 

move  a  directory  within  its  parent  (i.e.,  rename  ) 

add  sensitivity  marks  to  line  printer  output 

prevent  ip  from  accepting  requests 

system  activity  collection  program  directory 

collect  system  activity  data 

collect  system  activity  data 

collect  system  activity  data 

SCSI  hardware  dependent  programs 

SCSI  format  command 

SCSI  hard  disk  error  correction  facility 

SCSI  labeling  routine 

SCSI  quick  copy 

SCSI  disk  information 

simplified  administrative  utility 

tape  control  program 

target  controlkr  definitions 

terminal  definition  directory 

terminal  definition  fen*  4425 
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/u8r/Iib/tenniiifo/6/630 

/u8r/lib/temunfo/A/ATT4426 

/a8r/lib/ternunfo/a/att4425 

/usr/mail 

/usr/spool 

/uBr/spool/cron 

/  usr/spool/cron /at jobs 

/usr/spool/cron/crontabe 

/oar/spool/cron  /crontaba/ adm 

/usr/spool/cron/crontabs/root 

/uar/apool/cron/crontabe/fys 

/oer/spooi/cron/crontabe/syaadm 

/usr/spool/lp 

/osr/spool/lp/interface 

/uar/spool/lp/interface/SSlO 

/uw/spool/lp/log 

/uar/apool/lp/model 

/usr/spool/lp/model/SSlO 

/uar/spool/lp/oldlog 

/asr/spool/lp/ontputq 

/  usr/apool/Ip/ pstatns 

/  usr/spool/lp /qstatus 

/usr/tmp 


terminal  definition  for  630 

terminal  definition  for  4425 

terminal  definition  for  4425 

the  mail  directory 

the  spool  directory 

cron  spool  directory 

current  at  jobs  directory 

current  cron  tables  directory 

adm  cron  table 

root  cron  table 

sys  cron  tabk» 

sysadm  cron  table 

Ip  spool  directory 

Ip  printer  interface  directory 

6310  interface  script 

Ip  log  information 

Ip  model  directOTy 

6310  model  script 

saved  log  infOTmation 

current  output  job 

Ip  status  file 

Ip  status  file 

the  /usr/tmp  directory 
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Appendix  E:  Evahiaied  Products  Listing 


Serial  No.  CSO-EPL-SUM-90/003 

HATING  MAINTENANCE  PRODUCT:  System  V/MLS  Release  1.2.0  and 

630/MLS  Release  1.2.0  running  with 
UNIX*  System  V  Release  3.1.1  on  the 
AT&T  3B2/500  and  AT&T  3B2/600 
minicomputers  and  the  AT&T  630  MTG 
terminal. 

0RI6INA1  EVALUATED  PRODUCT:  System  V/MLS  Release  1.1.2  and 

630/MLS  Release  1.1.2  running  with 
UNIX*  System  V  Release  3.1.1  on  the 
AT&T  3B2/500  and  AT&T  3B2/600 
minicomputers  and  the  AT&T  630  MTG 
terminal. 

VENDOR:  American  Telephone  and  Telegraph 

Co.  (AT&T) 

RATING  MAINTENANCE  DATE:  28  September  1990 

OVERALL  EVALUATION  CLASS:  Bl 


EVALUATION  SUMMARY: 

AT&T  has  maintained  the  Bl  rating  of  its  System  V/MLS  product,  through  participation  in 
RAMP.  Fot  mwe  information  on  this  evaluation  process  and  System  V/MLS  Rekase  1.2.0,  see  the 
new  Final  Evaluation  Report  Addendum  addressing  System  V/MLS  Release  1.2.0. 

PRODUCT  DESCRIPTION: 


UNIX  is  a  Rsistet  trademark  <A  UNIX  System  Laboratories,  lac. 
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ATJfT’s  System  V/MLS  Release  1.2.0  running  with  UNIX*  System  V  Release  3.1.1  (hereafter 
referred  to  as  System  V/MLS)  is  a  multi-level  secure  version  of  the  UNIX  System  V  operating 
system  for  the  AT&T  3B2/500  and  AT&T  3B2/600  minicomputers  (both  utilising  the  WE32100 
microprocessor  and  the  WE32101  memory  management  unit). 

System  V/MLS  is  a  multi-user,  multi-tasking  operating  system  that  can  support  up  to  48  concurrent 
users  on  a  3B2/500  and  up  to  64  concurrent  users  on  a  3B2/600.  System  V/MLS  maintains  UNIX 
System  V  application  compatibility,  is  compatible  with  the  System  V  Interface  Definition  (SVID), 
passes  the  System  V  Verification  Suite  (SVVS),  and  is  source  and  binary  code  compatible  with 
existing  programs,  provided  those  programs  do  not  require  modifications  to  the  System/V  MLS 
Trusted  Computing  Base  (TCB)  or  violate  the  system  security  policy. 

In  addition  to  using  the  traditional  protection  mechanism  of  the  UNIX  operating  system  to  provide 
discretionary  access  control,  System  V/MLS  also  provides  mandatory  access  control  to  limit  the 
distribution  of  information  to  only  those  users  who  have  been  authorised  for  it.  The  mandatory 
security  policy  is  consistent  with  the  Bell-La  Padula  model  and  conforms  with  DoD  policy.  System 
V/MLS  provides  a  flexible  labeling  scheme  that  supports  up  to  255  site  selectable  hierarchical 
classification  levels  and  1024  nonhierarchical  categories. 

The  administrator  has  the  capability  to  restrict  users  and  login  ports  to  selectable  classification 
ranges.  A  multi-level  mail  capability  allows  users  to  communicate  with  each  other  at  classifications 
defined  by  the  administrator.  System  V/MLS  enforces  a  security  policy  that  prevents  both 
unauthorised  declassification  of  information  and  unauthorised  modification  of  trusted  code.  The 
mandatory  access  controls  are  implemented  in  a  manner  analogous  to  the  traditional  UNIX 
commands  for  discretionary  access  control.  Other  commands  have  been  added  to  aUow  users  to 
create  discretionary  groups  on  the  system.  Furthermore,  users  can  change  levels  without  having  to 
log  out. 

A  random  password  generator  implements  the  algorithms  recommended  in  the  DoD  Password 
Management  Guideline,  CSC-STD-002-85.  Audit  trail  records  are  generated  for  security-relevant 
events  and  can  be  analysed  by  an  administrator  using  an  audit  trail  formatter.  A  trusted  path  is 
provided  at  login  time  to  ensure  that  users  are  communicating  with  the  TCB. 

The  630  Multi-Tasking  Graphics  intelligent  terminal  (630  MTG),  a  high-resolution,  multi-window 
graphics  terminal,  can  provide  the  user  with  up  to  seven  windows  on  each  of  two  System  V/MLS 
hosts.  The  security  label  of  the  contents  of  each  window  is  independent  of  the  labels  of  other 
windows.  A  'cut  and  paste'  capability  allows  the  user  to  simultaneously  edit  files  at  different 
security  levels  within  the  constraints  of  the  enforced  security  policy. 

System  V/MLS  also  provides  some  features  beyond  those  required  for  a  class  Bl  system.  These 
include  B2  trusted  path,  B2  subject  sensitivity  labels,  and  B2  device  labeling.  This  product 
participates  in  the  NS  A  Rating  Maintenance  Phase  (RAMP). 

ENHANCEMENTS; 

This  RAMP  action  introduces  the  following  improved  functionality  and  enhancements: 

The  audit  subsystem  now  includes  eight  additional  User  Level  Interface  channels.  These 
channels  can  be  opened  by  more  than  one  process  at  a  time. 
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The  630MTG  now  supports  two  hosts  of  equal  accreditation  ranges  simultaneously,  providing 
separation  between  the  hosts. 

Utilizing  the  630  MTG  windowing  features,  an  enhanced  trusted  path  mechanism  is  built  into 
security  relevant  commands.  This  mechanism  involves  displaying  a  separate,  uniquely 
distinguishable  trusted  path  window  for  secure  communication  between  the  user  and  the  TCB. 

The  windowing  features  are  also  used  in  the  new  user  interface  for  selecting  the  subject 
sensitivity  level  for  each  newly  created  window. 

Additionally,  declassification  via  the  "cut  and  paste'  option  has  been  added  to  the  630MTG 
including  confirmation  and  enhanced  auditing,  optionally  including  the  declassified  text. 
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